From: Ming Z. <bla...@gm...> - 2007-09-25 18:10:33
|
On Tue, 2007-09-25 at 14:04 -0400, Ross S. W. Walker wrote: > Ming Zhang wrote: > > > > On Tue, 2007-09-25 at 23:16 +0530, jagadish kumar wrote: > > > > > > > > > 2 ini are allowed to access same target, but only allow one > > > ini to > > > access at one time. > > > > > > > > > this is the case of a cluster, and in that case the client will use > > > RESERVE/RELEASE scsi commands or > > > Persistent reservation commands (PERSISTENT RESERVE OUT/ PERSISTENT > > > RESERVE IN). > > > As you know persistent reservation commands are not > > supported by IET. > > > > consider that target is not a disk target but a tape target. not all > > backup application send R/R. > > Ah, yes, shared tape devices. I would then do auto reserve/release > you don't even need the per-initiator patch either since an initiator > would never ever access the tape device over multiple sessions. what u mean auto r/r? ini A access target X, auto reserve, go ahead access. then ini B try to access, fail, sound ok. what if ini A access target X, auto reserve, go ahead access. ini A crash and broken in part; then ini B try to access, fail, sound not ok. ;) who clear the previous reserve? blindly reset? then means nobody will be blocked at all... > > If your doing it in your Type 01h device patch why not do put an auto > reservation routine in your op-code section along with appropriate > tests for the op-codes that represent data in/data out and send a > device busy response if the lun is reserved. You may need some way > to test for a dead reservation and issue a LUN reset and retry. > > I suppose this routine could be used for all scsi device types that > do not logically support multiple initiators. > > -Ross > > ______________________________________________________________________ > This e-mail, and any attachments thereto, is intended only for use by > the addressee(s) named herein and may contain legally privileged > and/or confidential information. If you are not the intended recipient > of this e-mail, you are hereby notified that any dissemination, > distribution or copying of this e-mail, and any attachments thereto, > is strictly prohibited. If you have received this e-mail in error, > please immediately notify the sender and permanently delete the > original and any copy or printout thereof. > -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -------------------------------------------- |