All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rickard Olsson <richie@webhackande.se>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Drive gone bad, now what?
Date: Fri Oct 24 00:22:01 2003	[thread overview]
Message-ID: <3F98B691.7090902@webhackande.se> (raw)
In-Reply-To: <16280.27367.874758.610758@gargle.gargle.HOWL>

John Stoffel wrote:

Gert> We've setup a simple server machine with a bunch of harddisks of
Gert> 60 and 80 Gb.

John> Did you just concatentate or stripe the data across all the drives?

Butting in, I would assume (dangerous, I know) concatenation and 
non-striped since that is the default LVM mode when creating LVs. This 
is the exact same setup I have, BTW.

John> If you had just a simple concatenation of all the disks, then you are
John> toast.  How do you expect LVM to restore the missing 60gb if there's
John> no parity information or mirrored blocks?  It's impossible!

Yes, but he can restore the LV (sans the missing 60 gigs, of course) and 
access the rest of the archive. I believe that's what he's after.

Gert> For now we let the system rest until lvm2 matures and maybe the
Gert> tools will be there to rescue this set of disks

The tools are already here. I did the same thing a while back. But it 
ain't always easy. :-)

Go back to LVM1. Then, find another disk with the _exact same size_ as 
the deceased disk. Plug it in and pvcreate it (unless the old one had a 
LVM partition, in which case you fdisk and create a LVM partition on the 
new one):
# pvcreate -ff /dev/ide/host0/bus1/target0/lun0/disc

Restore your metadata to the new, empty disk, so LVM can restore the LV:
# vgcfgrestore -n YourVGName /dev/ide/host0/bus1/target0/lun0/disc
# vgscan
# vgchange -ay
# reiserfsck --rebuild-tree /dev/YourVGName
# mount /dev/YourVGName

There are a number of pitfalls along the way (not finding a disk of the 
same size is probably #1, but there is a way. If you can't find one, 
pvcreate a larger disk with -s. Use vgcfgrestore -ll to list the VG 
metadata stored in the backup, including the exact size of the dead PV.) 
but this is the basic layout. Heinz was kind enough to walk me through 
this when I had problems so now I feel like an expert. ;-)

Gert> LVM seemed an easy way to expand when needed..

It is. It's also the primary reason I use it instead of RAID. However, 
if there's money behind the archive (in my case, there isn't) you can go 
for a hardware RAID solution that offers the ability to grow the RAID. 
You will still need a bunch of same-size disks, but I could live with 
that, maybe you could too.

You can also combine RAID and LVM in various ways in an attempt to 
minimize the need for spare disks and maximize the size of useable 
space. Perhaps one RAID-5 array of one size disks and use LVM to 
concatenate it with another RAID-5 set of differently-sized disks. You 
can use NFS or Coda to glue two or more file servers together over the 
network if you run out of physical space in one of the machines.

John> You've basically hit upon the basic tradeoffs here, though you're
John> missing a performance issue, in that you should really try to keep
John> just one drive per IDE channel if at all possible from a performance
John> point of view.

If he's doing the same trade-offs I am, he values size over performance 
(which is 'good enough' for many uses even with shared IDE channels).

    / Rickard Olsson,IT-Konsult/
   / Telefon: +46 70 635 01 42/
  / http://www.webhackande.se/

  reply	other threads:[~2003-10-24  0:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-17 15:10 [linux-lvm] RAID 1 on Device Mapper - best practices? John Stoffel
2003-10-17 15:29 ` Mike Williams
2003-10-17 15:51   ` John Stoffel
2003-10-17 15:56     ` [linux-lvm] " Måns Rullgård
2003-10-17 16:13     ` [linux-lvm] " Mike Williams
2003-10-22  8:02       ` wopp
2003-10-23 17:52         ` [linux-lvm] Drive gone bad, now what? Gert van der Knokke
2003-10-23 18:59           ` John Stoffel
2003-10-24  0:22             ` Rickard Olsson [this message]
2003-10-24 15:23               ` Gert van der Knokke
2003-10-27  8:59                 ` John Stoffel
2003-10-27 18:28                   ` Gert van der Knokke
2003-10-28  2:20                     ` Patrick Caulfield
2003-10-28 13:52                       ` Gert van der Knokke
2003-10-28 14:14                         ` Jayson Garrell
2003-10-28 14:30                           ` Gert van der Knokke
2003-10-28 15:36                             ` John Stoffel
2003-10-29  8:54                               ` Brian J. Murrell
2003-10-30  8:00                                 ` Petro
2003-11-26 10:15                                   ` Harri Haataja
2003-10-28 16:06                             ` Glen Harris
2003-10-28 14:55                         ` Chris Cox
2003-10-28  8:57                     ` Mark H. Wood
2003-10-28  8:40                 ` Mark H. Wood
2003-10-23 18:53         ` [linux-lvm] RAID 1 on Device Mapper - best practices? John Stoffel
2003-11-20  7:20         ` Gregory K. Ruiz-Ade
2003-11-20  8:33           ` [linux-lvm] " Måns Rullgård
2003-11-21 13:02             ` Micah Anderson
  -- strict thread matches above, loose matches on Subject: below --
2003-10-29  0:54 [linux-lvm] Drive gone bad, now what? Victor Tan

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=3F98B691.7090902@webhackande.se \
    --to=richie@webhackande.se \
    --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.