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

Florian Haas florian.haas at linbit.com
Mon Sep 14 16:56:03 CEST 2009


On 2009-09-14 16:50, FUJITA Tomonori wrote:
> On Mon, 07 Sep 2009 10:16:06 +0200
> Florian Haas <florian.haas at linbit.com> wrote:
> 
>> On 09/07/2009 08:00 AM, Florian Haas wrote:
>>> On 09/07/2009 07:58 AM, FUJITA Tomonori wrote:
>>>> On Mon, 07 Sep 2009 07:47:32 +0200
>>>> Florian Haas <florian.haas at linbit.com> wrote:
>>>>
>>>>>> What iSCSI initiator implementation do you use on Linux?
>>>>> For testing? I use open-iscsi on Debian lenny; the Debian package
>>>>> version number is 2.0.870~rc3-0.4. My sg3-utils package version (if
>>>>> that's of any help) is 1.24-2.
>>>> That's strange. open-iscsi doesn't send TARGET_REST.
>>> Interesting. Let me grab a packet dump and I'll be back in touch.
>> You're right, open-iSCSI apparently simply translates any host or "bus"
>> reset into a new login sequence. For device resets, it does use a Task
>> Management Function (0x02) of the type "LU reset" (0x05).
> 
> Mike posted a patch to add WARM_RESET support to open-iscsi. I lightly
> tested my patch to add TARGET_RESET to tgt and it seems to work.
> 
> FYI, sg_reset utility doesn't send TARGET_RESET so you need to modify
> it.

Then out of curiosity, how did you test TARGET_RESET when working over
open-iscsi?

>> Going back to my original problem, I've now sifted through packet traces
>> generated on the production iSCSI target server (the one that the MSCS
>> hosts talk to), and have encountered something that leaves me
>> confounded. This applies to both IET and STGT (hence yet another
>> cross-post to both lists), so it's either something that is wrong in
>> both implementation, or some breakage in MSCS. Perhaps someone can
>> enlighten me here.
> 
> Have you tried the latest git tree (the CAPACITY bug was fixed)?

Yes the capacity read seems to work OK now. Thanks. There still seems to
be an additional issue with regard to "bus resets" from the MS
initiator, but we're currently still investigating whether it's an
initiator or target issue.

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/20090914/37e7b97a/attachment-0001.sig>


More information about the stgt mailing list