linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Matt P" <slarty.tj@gmail.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Re: LVM + Multipathing
Date: Tue, 20 Feb 2007 11:03:56 -0600	[thread overview]
Message-ID: <859a78260702200903o14188cb1hf874d589c5204698@mail.gmail.com> (raw)
In-Reply-To: <20070220131909.GA26642@percy.comedia.it>

Your problem might be related to this bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213921

On 2/20/07, Luca Berra <bluca@comedia.it> wrote:
> On Tue, Feb 20, 2007 at 06:00:25PM +0530, Ritesh Raj Sarraf wrote:
> >Luca Berra wrote:
> >
> >> On Sat, Feb 17, 2007 at 09:52:27PM +0530, Ritesh Raj Sarraf wrote:
> >>>Hi,
> >>>
> >>>I have a question regarding the combination of LVM + Multipathing in a SAN
> >>>environment.
> >>>
> >>>I have a LUN mapped to a host using iSCSI. I have two two paths to the LUN.
> >>>This setup, using multipathing, provides me failover functionality.
> >>>
> >>>My question is how does LVM react to path failures ?
> >>>In a failover environment, multipathing can take upto 120 seconds to detect
> >>>that the active path to the LUN is no more available and then switch to the
> >>>secondary path. During this 120 seconds, how does LVM react ? Does it really
> >>>sense that the device is offlined ? Or that information is never passed to LVM
> >>>and it just allows I/O to happen leaving that responsibility to the
> >>>multipathing layer ?
> >>
> >> i believe LVM does not react at all.
> >>
> >
> >I brought this question because I'm seeing Filesystem READONLY issues when doing
> >a takeover/giveback.
> >
> >My understanding is that a filesystem usually goes read-only, only when it
> >senses errors in the drive. Now I believe LVM might the culprit because beneath
> >the filesystem and above the block device, LVM is the only layer.
> to clarify my point above:
> 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.
>
> L.
>
> --
> Luca Berra -- bluca@comedia.it
>         Communication Media & Services S.r.l.
>  /"\
>  \ /     ASCII RIBBON CAMPAIGN
>   X        AGAINST HTML MAIL
>  / \
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

  parent reply	other threads:[~2007-02-20 17:03 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
2007-02-20 17:03       ` Matt P [this message]
2007-02-20 17:13         ` [linux-lvm] " 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=859a78260702200903o14188cb1hf874d589c5204698@mail.gmail.com \
    --to=slarty.tj@gmail.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).