linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: f-lvm@media.mit.edu
To: linux-lvm@redhat.com
Subject: [linux-lvm] Does pv failure effect whole vg?
Date: Thu, 21 Jun 2007 23:14:57 -0400 (EDT)	[thread overview]
Message-ID: <200706220314.XAA27738@out-of-band.media.mit.edu> (raw)
In-Reply-To: <Pine.LNX.4.44.0706201722500.12479-100000@bmsred.bmsi.com> (stuart@bmsi.com)

    Date: Wed, 20 Jun 2007 17:36:23 -0400 (EDT)
    From: "Stuart D. Gathman" <stuart@bmsi.com>

    On Wed, 20 Jun 2007, Richard van den Berg wrote:

    > To answer my own question: when a pv is not available at boot time, the
    > vg using that pv does not come up. So splitting vgs makes sense when you
    > want to minimize the impact of one disk failure.

    Hmmm.  On AIX LVM, vgs still boot when physical volumes fail, provided
    there is a "quorum".  The metadata is redundantly stored on all PVs,
    so a "quorum" means that more than half of the metadata copies
    are available and at the same version.

    I think Linux LVM stores only metadata for that PV on a PV, but there
    is a backup in /etc/lvm.

    If the system truly won't boot with a failed disk, that kind of adds another
    reason why current LVM mirroring support is useless.

I can also confirm that Linux LVM won't activate a VG that's missing
PVs.  Under Ubuntu Breezy, I had a VG divided into one tiny LV for
the usual OS dirs (/bin /etc /home /var etc etc) and one large LV
(spanning both the boot disk and a second disk) for a single large
filesystem.  While I was doing some hardware reconfiguration (details
irrelevant), I tried booting with the second disk disconnected, and
LVM couldn't activate any of the VG, including the LV that held the OS
itself, even though that LV definitely didn't cross into the second
disk.  (It was created months before the second disk was added, was
never extended, and thus consisted of a single PV.)

Once I discovered that, and since I was reconfiguring how its disks
worked anyway, I started over and created two VGs.  The first held a
single LV, which held the OS, and the second VG held another LV, which
spans boths disks and holds the large filesystem.  -That- will boot
with the second disk disconnected:  the first VG is activated and the
OS boots, and the second VG won't activate (unless, I assume, I force
it with --partial) because it's missing one of its PVs, but since the
filesystem that the OS is on isn't in that VG, at least the machine
boots.

(Yes, it'd probably be possible to make my own initrd that did
everything the normal one does but supplies --partial in the right
place, but that'd be a total pain to keep up-to-date across every
automatic kernel update, etc.  Given that I knew I'd be blowing away
the entire disk structure and starting over, it was far easier to just
create two VGs; presumably there'd have been some sneaky way [not using
the normal LVM API] to have changed the on-disk data structures in-place
if I'd been desperate, since in theory nothing about the size or placement
of the LVs would necessarily have changed.)

  parent reply	other threads:[~2007-06-22  3:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-19  6:39 [linux-lvm] Does pv failure effect whole vg? Richard van den Berg
2007-06-20 17:57 ` Richard van den Berg
2007-06-20 21:36   ` Stuart D. Gathman
2007-06-21  7:43     ` Richard van den Berg
2007-06-21 14:45       ` Stuart D. Gathman
2007-06-21 16:31         ` Richard van den Berg
2007-06-22  3:14     ` f-lvm [this message]
2007-06-24 15:43       ` Nix

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=200706220314.XAA27738@out-of-band.media.mit.edu \
    --to=f-lvm@media.mit.edu \
    --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).