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

[Lars Ellenberg]

On Mon, Sep 14, 2009 at 11:50:30PM +0900, 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.
> 
> 
> > 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)?

Thank you very much for all your effort.

Yes, there has been a working MSCS cluster confirmed
with iSCSI quorum disk against tgtd.
Unfortunately the installation where the problem occured first,
and triggered our investigation, still does not behave.
Though it gets slightly further now.

Our current assumtion is that the MS iSCSI Initiator there
is misconfigured, or misbehaving, or both, or lacking some
"hotfix".

Of course we have been investigating the initiator side as well, all
along.  Though that is unfortunately not that easy as with the OSS
target side.  Which is why that side of the investigation takes so much
more time :(

If only "enterprise" would finally reconize this advantage:
once you hit problems, with OSS, response times are much faster.
That alone should be a good reason to pay for OSS ;)

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
--
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