From: Dave Wysochanski <dwysocha@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Re: Re: LVM + Multipathing
Date: Wed, 28 Feb 2007 13:30:37 -0500 [thread overview]
Message-ID: <1172687437.4270.17.camel@linux-cxyg.rtp.netapp.com> (raw)
In-Reply-To: <mdera4-bvp.ln1@www.researchut.com>
On Tue, 2007-02-20 at 20:19 +0530, Ritesh Raj Sarraf wrote:
> Luca Berra wrote:
>
> > i meant that LVM (actually device-mapper) does not do anything special.
> > it just passes the IO requests from the fs layer to the
> > underlying block device and if the underlyng block device returns an IO
> > error then it is passed back to the fs. which will cause ext2 to remount
> > the filesystem readonly.
>
> Hi,
>
> Thanks for clarifying.
>
> In my case, the block device is hidden by the multipathing layer.
> It is something like:
> (Block Device(Multipathing(LVM(Filesystem) ) ) )
>
> Now during takeover/giveback, the multipathing layer is intelligent enough to
> wait till <120 seconds before declaring that the path has really gone offline
> and no more paths are available.
> If within the 120 seconds time span, the takeover succeeds, the path is back
> online and everything works fine in a non-LVM setup.
>
> It is only in an LVM setup that a takeover/giveback ends up with the host OS
> having a filesystem read-only problem.
Interesting.
> Now if I go with your explanation, I shouldn't have had the filesystem read-only
> problem since the I/O is being passed on to the multipathing layer which is
> intelligent enough to wait for N seconds before really sending an I/O Error.
>
> Are there any timeout options in LVM to allow it to wait for N seconds before
> sending out an error ?
> (I understand that LVM might not be involved, but just wondering).
>
There are no LVM timeouts like you are suggesting. LVM just does I/O to
devices like any other application. The timeout settings you're looking
for should be in the layers below LVM.
What does your /etc/multipath.conf file look like? Do you have
"no_path_retry" set and/or "queue_if_no_path"? Both of these settings
will affect how multipath deals with a "no paths available" situation.
There are also settings below multipath, in the low-level driver(s).
Since you are using iscsi, I assume you've got open-iscsi?
You can set node.session.timeo.replacement_timeout to a lower value (it
is 120 by default in /etc/iscsi/iscsid.conf) if you want faster path
failure detection and faster failover.
In a lot of cases, people set the low level driver timeouts smaller (<
30 sec) to allow for quicker failure detection and failover, but a
higher or infinite value for the "no paths available" situation.
You might try open-iscsi.org and/or dm-devel lists.
>
> Thanks,
> Ritesh
next prev parent reply other threads:[~2007-02-28 18:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-17 16:22 [linux-lvm] LVM + Multipathing Ritesh Raj Sarraf
2007-02-20 6:11 ` Luca Berra
2007-02-20 12:30 ` [linux-lvm] " Ritesh Raj Sarraf
2007-02-20 13:19 ` Luca Berra
2007-02-20 14:49 ` [linux-lvm] " Ritesh Raj Sarraf
2007-02-28 18:30 ` Dave Wysochanski [this message]
2007-02-20 17:03 ` [linux-lvm] " Matt P
2007-02-20 17:13 ` Christian.Rohrmeier
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=1172687437.4270.17.camel@linux-cxyg.rtp.netapp.com \
--to=dwysocha@redhat.com \
--cc=linux-lvm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).