SSD Partitioning OP/Trim recommendations

[Chris Murphy]

On Dec 18, 2013, at 8:50 AM, Richard Shaw <hobbes1069 at gmail.com> wrote:
> 
> This makes even less sense for a laptop, but lets look at a desktop situation. Sure you could add a second disk, add it to your volume group, add space to your LV, and resize your filesystem to use it. One problem though, you've created another point of failure for your FS (two disks) without getting anything in exchange.

Yes, I agree it's a problem short of a way to mitigate the (inevitable) failure of one of the disks and hence any file system that uses all or part of a failed PV.

> It's not striped (you can do LV striping, but that's another discussion altogether), it's not mirrored, there's no parity. So why do it?

pvmove is a pretty cool way to move every LV, online, to a new PV. But I agree LVM is overly complicated for such hypothetical benefits. Benefits that assume more knowledge on the part of the typical user than is true. It's much simpler to just backup, and restore to a new bigger disk, than to learn various LVM commands.

For what it's worth, LVM2 supports its own raid0, 1, 5 and 6. Those raid levels are LV attributes. So instead of configuring different raid levels by using disk partitions, and the ensuing near impossibility (or madness) of resizing them should it be needed, this can be done on a per LV basis from a single VG. It's "simpler" in that there's one less layer to deal with, however it means learning totally new vernacular and monitoring methods which itself isn't exactly simple.

> In a server/enterprise setting I think it makes a lot more sense where you're likely to need to use LVM to span across multiple raid arrays, SANs, etc.

I think LVM is pretty bad ass.  During F18 pre-release, the installer team had moved to Standard Partition scheme (all ext4) by default. But for the very reasons you mention, I was opposed to LVM by default redux, but the LVM camp won that argument somehow.

Another place it makes some sense is full disk encryption (i.e. not just home), where the PV/VG is encrypted, and then the LVs are drawn from that. That's simpler than separately encrypting partitions for /home and /. Assuming you want /home separate.

Honestly a lot of these things get easier with Btrfs due to yet another loss of a separate layer. It's as simple to use as a plain file system without thinking of esoteric features if you don't want, but they're there should you need them: compression, much safer fs resize shrink or grow, partitioning without having to specify sizes, functional equivalent to pvmove, and even the ability to migrate specific "partitions" like /home to another disk, multiple device support, and of course snapshots. Plus it's also friendlier to SSD than other options.

Chris Murphy