[stgt] stgt does not preempt SCSI-2 reservations; may break MS Cluster Service failover

[FUJITA Tomonori]

On Sun, 06 Sep 2009 22:57:17 +0200
Florian Haas <florian.haas at linbit.com> wrote:

> On 09/05/2009 10:53 AM, FUJITA Tomonori wrote:
> > On Thu, 03 Sep 2009 07:40:43 +0200
> > Florian Haas <florian.haas at linbit.com> 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 at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html