> > >
> > > 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".
i think these information are what we need. but i am a little worry that
this violate the layered idea. seems we want SCSI CDB to carry many non-
SCSI stuff. This might not be a logic way even this is a easier hack.
Hard to say now. :P
> 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. :)
>
> >
> >
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
|
