From: Mike Christie <michaelc@cs.wisc.edu>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: DM-Multipath path failure questions..
Date: Wed, 14 Nov 2007 11:28:37 -0600 [thread overview]
Message-ID: <473B3045.8060406@cs.wisc.edu> (raw)
In-Reply-To: <20071114000743.3b2d36a5.vaio@nolatency.com>
Michael Vallaly wrote:
> Hello,
>
> I am currently using the dm-multipather (multipath-tools) to allow high-availability / increased capacity to our Equallogic iSCSI SAN. I was wondering if anyone had come across a way to re-instantiate a failed path / paths from a multipath target, when the backend device (iscsi initiator) goes away.
>
> All goes well until we have a lengthy network hiccup or non-recoverable iSCSI error in which case the multipather seems to get wedged. The path seems to get stuck in a [active][faulty] state and the backend block device (sdX) actually gets removed from the system. I have tried reconnecting the iSCSI session, after this happens, and get a new (different IE: sdg vs. sdf) backend block level device, but the multipather never picks it up / never resumes IO operations, and I generally have then to power cycle the box.
>
> We have anywhere from 2 to 4 iSCSI sessions open per multipath target, but even one path failing seems to cause the whole multipath to die. I am hoping there is a way to continue on after a path failure, rather than the power cycle. I have tried multipath-tools 0.4.6/0.4.7/0.4.8, and almost every permutation of the configuration I can think of. Maybe I am missing something quite obvious.
>
I was wondering what you are doing on the target to cause the device/sdX
to be removed or what error you get? Normally that only happens if you
run the iscsiadm logout command, or if the target is sends the initiator
a error indicating that is going away for good, or there is some other
error like the CHAP values changed on the target. And in older versions
of open-iscsi there is a bug where it kills the session and removes sdXs
a little early on errors that should be recoverable (We found the bug in
865-* but this is fixed in the open-iscsi git tree and will be fixed in
the new release), so I just want to make sure I got all the recoverable
errors.
What kernel are you using, and what happens when you reconnect the
session and get a new sdX if you run the multipath command by hand?
next prev parent reply other threads:[~2007-11-14 17:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 6:07 DM-Multipath path failure questions Michael Vallaly
2007-11-14 17:28 ` Mike Christie [this message]
2007-11-14 22:33 ` Michael Vallaly
2007-11-14 18:26 ` Kevin Foote
2007-11-14 21:44 ` Michael Vallaly
2007-11-14 23:39 ` Michael Vallaly
2007-11-15 4:55 ` Kevin Foote
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=473B3045.8060406@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.