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

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Mon Sep 14 16:50:30 CEST 2009

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

> 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)?
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

More information about the stgt mailing list