== The temptation of LVM 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.