[lug] LVM and disk failure

[Nate Duehr]

Daniel Webb wrote:
> Thanks for the info, that clears it up some.  What it comes down to, is that
> LVM increases flexibility at the price of robustness in the case of a physical
> volume failing.  As a result, you want your physical volumes to be *very*
> unlikely to fail.  

No, just remove that last part of the sentence.  LVM never has any
result at all on robustness.  Only stuff like software and hardware RAID
have any impact on that...

> Absurdum infinitum: suppose you created a volume group out of 1000 RAID-1
> pairs.  Now if you put a logical volume spanning the whole volume group, and
> one RAID pair dies for whatever reason, the whole thing is gone.  So if N is
> the number of physical volumes in your volume group, you should plan for them
> to be N times less likely to fail to get the same chance of overall failure as
> a single disk.

You don't do that.  ;-)

You use LVM to get whatever "virtual sized disk" you need for your data,
and then you RAID that virtual disk if you need more than your backups
can give you in fault-tolerance.

> Also, if you can use the 1000 disks without LVM (maybe you have 1000 files
> that just fit each disk), it would be smarter not to use LVM.

There are times this is true.  If you have a multi-terrabyte data set
that all needs to live in one directory because some programmer hard
coded the program, then you need LVM.  If you don't want to have 1000
mount points, you use LVM.

> But back to part of my original question that wasn't answered: it seems a bit
> silly to me that a filesystem is utterly destroyed if you cut it in half;
> after all, half of it is still there on the second disk.  A reasonable request
> in the name of robustness is that the parts that weren't destroyed should be
> recoverable without a huge amount of trouble.  Is that too much to ask?  I
> don't really know that much about filesystems, so maybe there are reasons this
> is impossible.  And yes, I have seen plenty on recovering ext2 filesystem from
> the Google searching to try to answer these questions, it isn't pretty.

The inode tables and superblocks are in specific locations within the
filesystem, on many filesystems.  There are filesystems that have more
chance of recovery than others, but they have to store lots of meta-data
 on the disk platter right next to every file.

RAID implementations have proven to be a much more efficient use of the
same disk space.

Nate