From: Kevin Corry <corryk@us.ibm.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Disk Died - Ideas?
Date: Thu, 27 Sep 2001 10:32:44 -0500 [thread overview]
Message-ID: <01092710324404.08721@boiler> (raw)
In-Reply-To: <20010927095516.C19527@turbolinux.com>
> > <broken record>
> >
> > boot once.
> >
> > vgexport /dev/vgwhatever;
> > vgimport /dev/vgwhatever <list of drives that didn't croak>
> >
> > you will now have your VG back on line with whatever portion of the
> > data is no the clean drives. any LV's spanning the dead drive are
> > likely to be lost anyway. It'll take you less time to vgextend the
> > imported group onto a new, working drive an recover backups onto
> > new LV's than almost anything else you can try.
> >
> > </broken record>
>
> bzzzt. This _may_ work on HPUX and AIX, but I _highly_ doubt it will
> work with Linux LVM. The Linux LVM code requires that all of the disks
> be present, and that they all have the correct data (no metadata backups
> yet). You could hack the vgscan code so that it doesn't require this,
> but it would probably end up causing grief somewhere else before you
> could actually read from the LV.
I'd agree with Andreas. I have tested this situation, and the
vgexport/vgimport method isn't always guaranteed to work. If you have run
vgscan at any point after a PV is lost, the VG will no longer be recognized,
and you can't run vgexport anymore. It just complains and tells you to run
vgscan again.
> AFAIK, not even HPUX or AIX would allow you to read from a partial LV
> (which is the situation we are discussing here), so it wouldn't help.
> What _would_ be very useful is a tool that reads the LVM metadata
> directly, creates a list of available LEs (in order) and dumps them
> to a file, writing zeros for LEs that are not available (and writing
> large warnings for each missing LE).
EVMS already does this. It is perfectly happy recognizing partial volume
groups, and exports any complete volumes it finds in such a group. Any
incomplete volume in the group (one that had data on the lost disk) will be
exported read-only, so you can at least do a raw backup of whatever data is
left, or use some sort of filesystem recovery tools if they are available for
your fs.
-Kevin
next prev parent reply other threads:[~2001-09-27 15:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-25 15:02 [linux-lvm] Disk Died - Ideas? Jeff Layton
2001-09-25 16:56 ` lembark
2001-09-25 17:09 ` Andreas Dilger
2001-09-27 11:39 ` Jeff Layton
2001-09-27 14:40 ` Steven Lembark
2001-09-27 15:55 ` Andreas Dilger
2001-09-27 15:32 ` Kevin Corry [this message]
2001-09-27 16:09 ` Steven Lembark
2001-09-27 15:42 ` Andreas Dilger
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=01092710324404.08721@boiler \
--to=corryk@us.ibm.com \
--cc=linux-lvm@sistina.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.