On Sun, 06 Sep 2009 22:57:17 +0200 Florian Haas <florian.haas@xxxxxxxxxx> wrote: > On 09/05/2009 10:53 AM, FUJITA Tomonori wrote: > > On Thu, 03 Sep 2009 07:40:43 +0200 > > Florian Haas <florian.haas@xxxxxxxxxx> wrote: > > > >> Fujita-san, > >> > >> On 2009-09-02 07:02, FUJITA Tomonori wrote: > >>> You mean that MSSC sends TARGET_WARM_RESET (or TARGET_COLD_RESET)? > >>> Note that there is no 'bus reset' thing. > >> In SCSI2, TARGET_RESET was called BUS_DEVICE_RESET (at least in the > >> defines inside the Linux source tree). > >> > >> And yes, the Windows SCSI stack does a "SCSI bus reset", colloquially > >> speaking, whatever that is translated to in iSCSI speak. > > > > 'SCSI bus reset' is really old and obsolete, I think. > > FWIW, sg_reset from sg3-utils uses the term "bus reset" both in its man > page and in its '--help' output. That's a fossil. The 'bus' concept in SCSI has gone long time ago. > >>> BTW, IET doesn't correctly handle any reset commands (i.e. it doesn't > >>> handle UA). I wrote IET so I know exactly what it does. > >> Yes, I know you wrote it, and I know it does not handle the Unit > >> Attention stuff, but at least it preempts the SCSI-2 reservations > >> on target reset. Does it not? > > > > If just preempting the reservation on target reset (as IET does) works > > for you, the following patch might work (sorry, I've not tested the > > path at all because open-iscsi doesn't support > > TARGET_WARM|COLD_RESET): > > Unfortunately the patch does not work for me, using the sg_raw/sg_reset > procedure I described earlier in this thread. Hmm, I'll look at the code again. What iSCSI initiator implementation do you use on Linux? > I can now do a "bus reset" with "sg_reset -b <device>", and it does > complete. But attempting a reservation thereafter still results in a > reservation conflict. To complicate matters, attempting another RESERVE > from the same host, on the same device, now results in a reservation > conflict too. Complicating things still, attempting a RELEASE on a > previously RESERVEd LU, on the same host now results in a reservation > conflict as well. Effectively, after a bus reset, once-acquired > reservations are completely broken: they can't be released, and they > can't be re-acquired. > > The same thing is true when attempting to preempt a reservation via a > host reset (sg_reset -h <device>). Only a device reset preempts the > reservation correctly. > > Hope this helps. I'll be happy to test an updated version of the patch > if I can be of help. > > Best regards, > Florian > -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
