On Thu, 2005-07-14 at 16:20 -0400, Ming Zhang wrote:
> On Thu, 2005-07-14 at 15:16 -0500, Brian Wolfe wrote:
> > On Thu, 2005-07-14 at 16:11 -0400, Ming Zhang wrote:
> > > but the backup client still need to behave like a requester to keep ini
> > > side data consistent before invoking snapshot request. so it is possible
> > > to let this signal still sent by ini.
> > >
> > >
> > > ming
> >
> > Couldn't the backup client have the permission to ask the OS to pause
> > things and confirm the pause, then the client would request the snapshot
> > to the management server, get confirmation back and inform client's
> > kernel to release to full use once more?
> could. :P
>
>
> >
> > I can't see the need for the kernel(iscsi initiator) to be the one
> > asking for management tasks of the storage server if there were a
> > os-specific standardized way of requesting fs pausing. After all it's
> > the backup client that needs to coordinate the creation/removal of the
> > snapshot image at the storage server level, not the kernel that the
> > backup client is running on. It jus doesn't feel right to me when I
> > imagine using iscsi as the management communication channel....
> our first consideration is that since VSS provider has all the knowledge
> and control, it is easy for it to send a specific SCSI CDB to invoke the
> snapshot. of course, it also can send a standardized command to
> management daemon on IET via another channel other than iSCSI. this way
> ease the development to have a extra channel.
>
>
> ming
After some more thought, we already are using iscsi as a management
channel. User authentication. So if snapshot requesting were to use this
channel, it would be a simple "make snapshot, reply with target/lun"
plus optional config info of "allow client X from a.b.c.d RO access".
SO creating an out of band link seems out of place now with the iscsi
protocol the more I think about it.
I guess i'm just thinking of iscsi as being too closely bound to being
like my limited knowlege of traditional scsi.
I knew there was a reason why yall are the ones coding this stuff and
not me. :)
>
>
signature.asc
Description: This is a digitally signed message part
|
