Once upon a time, m.roth@xxxxxxxxx <m.roth@xxxxxxxxx> said:
> Here's a question: all of the arguments you're giving have to do with VMs.
> Do you have some for straight-on-the-server, non-VM cases?
I've used LVM on servers with hot-swap drives to migrate to new storage
without downtime a number of times. Add new drives to the system,
configure RAID (software or hardware), pvcreate, vgextend, pvmove,
vgreduce, and pvremove (and maybe a lvextend and resize2fs/xfs_growfs).
Never unmounted a filesystem, just some extra disk I/O.
Even in cases where I had to shutdown or reboot a server to get drives
added, moving data could take a long downtime, but with LVM I can
live-migrate from place to place.
LVM snapshots make it easy to get point-in-time consistent backups,
including databases. For example, with MySQL, you can freeze and flush
all the databases, snapshot the LV, and release the freeze. MySQL takes
a brief pause (few seconds), and then you mount and back up the snapshot
for a fully consistent database (only way to do that other than freezing
all writes during a mysqldump, which can take a long time for larger
DBs). That also avoids the access-time churn (for backup programs that
don't know O_NOATIME, like any that use rsync).
That's server stuff. On a desktop with a combination of SSD and
"spinning rust" drives, LVM can give you transparent SSD caching of
"hot" data (rather than you having to put some filesystems on SSD and
some on hard drive).
Now, if btrfs ever gets all the kinks worked out (and has a stable
"fsck" for the corner cases), it integrates volume management into the
filesystem, which makes some of the management easier. I used AdvFS on
DEC/Compaq/HP Tru64 Unix, which had some of that, and it made some of
this easier/faster/smoother. Btrfs may eventually obsolete a lot of
uses of LVM, but that's down the road.
--
Chris Adams <linux@xxxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
