SSD Partitioning OP/Trim recommendations

Chris Murphy lists at colorremedies.com
Wed Dec 18 18:51:49 UTC 2013


On Dec 18, 2013, at 8:15 AM, Mihamina RKTMB <mihamina at rktmb.org> wrote:

> On 12/18/2013 04:38 PM, Robert Moskowitz wrote:
>> Also discourages using LVM.  I have often wondered why I use LVM on my notebooks; I don't see the gain over just plain EXT4 partitions.  I have read a number of articles and I can't find any solid advantage.
> 
> Well, I dont have a notebook, but a laptop (16GB RAM, Corei7-8 threads, 512 SSD Samsung 840 Pro)
> I use it for work, and I heavily virtualize on it.
> I have 1LV per VM. VMs are "small" (2GB RAM, 5GB disk space), but they are numerous (mostly 4-5 VMs turned on)
> When I clone a VM, the LV gets cloned too.
> I find it very usefull and clean on the drive.

Two other options exist, but first a disclosure being that there are always a bunch of ways to do one thing on linux. And a lot of times it's about comfort level and familiarity rather than what's "best".

The critique I'd apply to using LV's as backing for VM's is that they allocate all of that space - it's taking out of the VG.  So you have to plan in advance accordingly to avoid over committing space that is now no longer in the VG. You can resize but… now that's another series of steps, and you may be resizing again in the future.

So while I used to use LVs for this task, I'm now using qcow2 files. I create one, install once, and then snapshot the qcow2 five times (for five VMs) and have the VMs use the snapshots. The backing qcow2 isn't ever modified from that point forward, only the snapshots are. Since they're sparse, they only take up the space that's actually being used. They're easy to backup, etc.

Another option, that's quite new and probably still needs testing, is LVM Thin Provisioning. There's an extra layer between the VG and LV called the thin pool. LV's are created with a virtual size, meaning they simply get tagged as being that size (think of it as a maximum) but extents aren't taken from the thin pool until needed by any LV using that pool. So instead of creating 5GB LVs, you can create 50G LVs "just in case" it's needed. If one LV needs 1GB, then only 1GB of extents are used in the pool the rest are available to other LVs. Also, it's possible to get efficient snapshotting unlike conventional LVM snapshots. So you can create an LV, install a system, snapshot it to create other LVs and use them as your VM backing. No preallocation for snapshot space required, it draws extents from the pool as each VM's LV needs to grow with changes.


Chris Murphy


More information about the users mailing list