From: Ming Z. <bla...@gm...> - 2007-09-25 18:19:49
|
On Tue, 2007-09-25 at 14:16 -0400, Ross S. W. Walker wrote: > Ming Zhang wrote: > > > > On Tue, 2007-09-25 at 14:04 -0400, Ross S. W. Walker wrote: > <snip> > > > > > > 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? > > I mean the target software does the reserve/release internally > independent of the initiator, which I suppose doesn't support it. > > > 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. ;) > > Yes, that is why you would need to test for a dead reservation and > if so do a LUN reset and then retry establishing reservation. how u know it is a "dead" reservation? A reserve LU; B try to access and refused. shall B issue a LUN reset now? > > > who clear the previous reserve? blindly reset? then means > > nobody will be > > blocked at all... > > Follow the SPEC and then it should behave properly even when initiators > that end up supporting reserve/release SPEC join the mix. > > > > > > 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. > > ______________________________________________________________________ > 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 -------------------------------------------- |