[Discuss] LVM Re: A really interesting chain of functionality

[blu at nedharvey.com (Edward Ned Harvey)]

> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Tom Metro
> 
> Generally speaking, the whole LVM concept seems quaint and requires a
> lot of manual management. I haven't deployed it on a system since 2006.
> Unfortunately, there aren't good alternatives for it on Linux.

I have two modern-day real-life uses for LVM:

(1)
ext4 supports easy expansion, but not easy shrinking.  No snapshots.  It
supports quotas.

btrfs supports easy expansion and shrinking, and snapshots, but no quotas
(yet).

Instead of creating a btrfs volume and accepting the lack of quotas, I use
LVM to chop the storage into pieces, which essentially imposes quotas.  Then
I use btrfs inside the logical volumes.

(2)
Having become accustomed to ZFS send/receive, and the availability of
snapshots to recover individual files instantly... I wanted to find a way to
gain this functionality on systems using ext3 and dump for backups.  I
settled on this:

Server A is backing up to Server B.  Disk to disk.  Server B has one big LVM
volgroup.  Just before the level 0 dump, Server A detects how much space
it's used, and tells Server B to allocate that much, multiplied by a
constant.  Server A sends the dump, which Server B saves into a dumpfile,
and simultaneously restored into a filesystem.  Each day, Server B will
store the incremental dumpstream into a file, and restore into a separate
directory.  So at any given time, you can browse and restore individual
files without needing to read the *whole* dumpstream.  Yet the whole
dumpstream is available, in the event you need it for disaster recovery of
Server A.  This cuts the individual file restore time from something like a
day or two, down to a second or two.  (Sure it comes with a disk cost, but
that cost is at most 2x and typically less than 2x.)  Previously whenever a
user requested some file restored, I'd have to "cat dumpfile.gz | gunzip |
restore -if -" ... and a day or two later I'd be able to give them their
files, which they've recreated from scratch by now.

Why do I care about using LVM for this purpose?  Because each time you send
a new level 0 and delete the oldest level 0...  "rm -rf" on that quantity of
data takes a long ass time.  But "lvremove" is instant.  Plus I'm always
fearful for script bugs when I use "rm -rf."  But lvremove will fail in
pretty much any situation other than the intended situation...  Won't remove
a volume that's active, won't remove anything that isn't actually a LVM
logical volume...  Etc.  

Yes you could do a lot of this using btrfs, but there are so many features
currently supported by ext3/4 that are as-yet unsupported by btrfs...  Not
to mention the fact that btrfs is as-yet unavailable in RHEL/Centos...