The temptation of LVM

September 15, 2006

Generally I'm not a big fan of LVM. It has a lot of moving parts, adds an extra layer of indirection, and the whole set of commands and tasks has always felt rather complex; there was too much fan dancing for the results I'd get.

But I have a new machine to set up, and I have to say that modern disks have really made LVM tempting. The problem is that they've gotten so big that I no longer have any idea what I want to do with all of the space.

(This is not quite true: I know what system partitions I want and roughly how big I want them. But that's a drop in the bucket on a modern disk; even with generous sizes to fend off distribution bloat, I'm not going to use more than 50G.)

One approach, which we used on another system, is to throw all of the space into one big /data partition, then do bind mounts to create the user-visible 'filesystems'. This has the virtue of not limiting how much space you can use for anything in particular, but the drawback that if your filesystem gets corrupted you lose big.

The temptation of LVM is that with LVM, I can defer the issue and change my mind as much as I want. I can carve out some starting filesystems with relatively modest sizes and leave the rest of the space unallocated; as I get a better idea of how I'm going to use the system, I can grow filesystems or make new ones. And if my usage patterns change later, I can shrink things or drop surplus filesystems entirely.

This would give me the benefits of a big common storage pool, without having to have one huge filesystem. All I'd have to do is accept into my life the overhead of dealing with LVM and whatever performance hit it and non-contiguous filesystems have.

It's a very strong temptation. But it makes me feel guilty; I feel that by all rights I should be able to plan my filesystems out ahead of time, and resorting to LVM would just be the lazy, wimpy way out.


Comments on this page:

From 24.98.83.96 at 2006-09-16 09:20:33:

This is the exact issue that Sun's ZFS file system solves. You toss a bunch of disks into a pool with the zpool command, and use 'zfs create filesystem_name' to create one or more file systems in that pool. If you need to grow the pool, you just toss some additional disks into the pool. If you need to limit the size of a filesystem in a pool, you set a quota, which can be increased or decreased at any time. In addition to those nifty features, ZFS also checksums every block of data (and metadata) to ensure that your data is safe, and allows you to "thin" provision storage (which is SUPER useful when presenting iSCSI targets to clients). You can read more about ZFS on the opensolaris.org website:

http://opensolaris.org/os/community/zfs/

Having spent the past several years working with Linux LVM, Linux MD, VxVM and SVM, this is the simplest and most robust file system / volume manager I have ever used.

- Ryan

From 221.122.43.98 at 2007-03-08 21:24:16:

The management of LVM volumes got a lot easier for me when I discovered the short-form commands: pvs, vgs, and lvs, which show the physical volumes, volume groups, and logical volumes, respectively. Very handy.

-- Darren Griffith

By cks at 2007-03-08 22:38:57:

I'm not really bothered by the commands (although knowing the short forms is useful). The LVM overhead that concerns me is more conceptual, in keeping track of all of its terminology and levels and bits and pieces; it is just complicated, especially when I'm layering it over software RAID 1 to start with.

(I have the impression that this is one of the things Sun did with ZFS in Solaris 10: they figured out what was really necessary and simplified the terminology and the layers down to that.)

Written on 15 September 2006.
« A bonus to writing documentation
Weekly spam summary on September 16th, 2006 »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 15 22:31:30 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.