CentOS - Jun 2015 - LVM hatred, was Re: /boot on a separate partition?

Once upon a time, m.roth at 5-cent.us <m.roth at 5-cent.us>
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 at cmadams.net>

On 6/24/2015 2:06 PM, Chris Adams wrote:
> Once upon a time, m.roth at 5-cent.us <m.roth at 5-cent.us> 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.
This is one of my primary use cases, and a real big time saver.  I do 
this allot when migrating Oracle DB LUN's to larger sized, new 
allocations.  It works great weather you are using ASM or any Linux 
filesystem.  It is especially handy when migrating from one SAN frame to 
another.  You can fully migrate with zero down time if you do even a 
small amount of planning ahead.

There are just so many time saving things you can do with it.  Sure, if 
all groups in the chain plan ahead properly there can be very little 
change needed but how often does that happen in real life? It is part of 
my job to plan well enough ahead to know that storage needs grow despite 
everyone's best intentions to get out of the gate properly.  LVM makes 
growing much easier and flexible.

On 06/24/2015 12:06 PM, Chris Adams wrote:
> 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.
Exactly.  And I mention this from time to time... I'm working on 
infrastructure to make that more common and more consistent:
https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot

If you're interested in testing or development (or even advocacy), I'd 
love to have more people contributing.
> That also avoids the access-time churn (for backup programs that
> don't know O_NOATIME, like any that use rsync).
Yes, though rsync based systems are usually always-incremental, so they 
won't access files that haven't been modified, and impact on atime is 
minimal after the first backup.
> 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).
Interesting.  I wasn't aware that LVM had that option.  I've been 
looking at bcache and dm-cache.  I'll have to look into that as well.
> 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.
btrfs and zfs are also more reliable than RAID.  If a bit flips in a 
RAID set, all that can be determined is that the blocks are not 
consistent.  There's no information about which blocks are correct, or 
how to repair the inconsistency.  btrfs and zfs *do* have that 
information, so they can repair those errors correctly.  As much as I 
like LVM today, I look forward to ditching RAID and LVM in favor of btrfs.

On 06/24/2015 12:35 PM, Gordon Messmer wrote:
> Interesting. I wasn't aware that LVM had that option.  I've been 
> looking at bcache and dm-cache.  I'll have to look into that as well. 
heh.  LVM cache *is* dm-cache.  Don't I feel silly.

On Wed, 24 Jun 2015 14:06:19 -0500
Chris Adams <linux at cmadams.net> wrote:

> 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.
https://en.wikipedia.org/wiki/AdvFS
AdvFS uses a relatively advanced concept of a storage pool (called a file
domain) and of logical file systems (called file sets). A file domain is
composed of any number of block devices, which could be partitions, LVM or LSM
devices.

I really miss this.
BR, Bob