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

[Florian Haas]

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.

>>> 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wpkg.org/pipermail/stgt/attachments/20090906/09d10ce3/attachment-0001.sig>