# LVM - Any benefit of Not Using the Whole Partition?

## dman777

I have 100gig SSD drive that I am going to use for KVM guests. At first I was going to just make one large partition for a VG and make each logical volume a KVM guest. I probably will plan on using 50% of it initially.  But then I read where I should not partition all the drive and only partition what I need for LVM. Is there any real benefit to making separate partitions of the SSD drive if I am eventually going to add them to the same Volume group anyways?

----------

## srs5694

AFAIK, no. IMHO, the benefit to creating a smaller LVM partition (physical volume) that's only as big as you need it to be is that you can then use the unpartitioned space for something else if you decide to do so. For instance, you could install another OS entirely in that space, for a dual-boot setup. If you're 100% certain that you'll never want to do this, there's little point to creating a smaller partition (which in turn means you'd need two or more physical volumes when you get around to using the space in the LVM).

----------

## depontius

Please check me if I'm wrong on this...

There might actually be some good in using LVM to make sure that the entire disk isn't available for use.  That gives the SSD control firmware more fodder to play with when remapping sectors to level wear.

This is dependent on the assumption that SSD firmware will take a region that has been historically read-mostly/only and swap it with a region that has been historically heavily written.  I don't know that this actually happens, but I get the impression that it does.

----------

## dman777

You are correct...this is for garbage collection. I already over provisioned and left 20 gigs of raw space for it. But as far as LVM goes, I was wondering if there is any benefit. Could the partition become messed up and having the extra partition be a benefit? I never really seen a partition get messed up before though. Would the LVM work quicker on two partitions of the same block device rather than one large partition of the same block device?

----------

## depontius

I actually don't like LVM after having used it,and have mostly removed it from use.  It adds another level of indirection into your data storage, potentially making it harder to pick up the pieces after a problem.  For what I would expect/wish out of LVM, fiddling with partition size and placement, I've been able to get that out of booting a gParted disk.

That said, I have 2 systems now (neither Gentoo) that use LVM as an encrypted container.  It's the "standard deployment", so I'm using it.  But in this case LVM does simplify life.

I believe the performance penalty for LVM is negligible, but neither do I envision it improving performance, either.  IMHO it's pretty much for convenience.

----------

## srs5694

 *depontius wrote:*   

> I actually don't like LVM ....  For what I would expect/wish out of LVM, fiddling with partition size and placement, I've been able to get that out of booting a gParted disk.
> 
> ...
> 
> IMHO it's pretty much for convenience.

 

The problem with using GParted for changing partition sizes is that it takes much more time and is much riskier. Consider a simple scenario:

```

[    Partition 1             ][   Partition 2   ]

```

Now suppose that partition 1 is too big and partition 2 is too small. You decide to adjust their sizes in GParted. This requires shrinking partition 1, which would be similar in risk and time to an equivalent operation with LVM. You'd then need to move and grow partition 2. Because moving a partition involves adjusting many of its internal data structures, this operation takes much longer than does growing a partition into free space after it, and it takes much longer. For both of these reasons, the risks associated with the operation greatly increase. (Theoretically you could move the start of partition 2 rather than move it and then grow it, but in practice I believe GParted breaks this into two operations. Even as one operation, though, the problems I've identified would still exist.)

With LVM, by contrast, instead of moving data structures in logical volume 2, space between the two original logical volumes is allocated to hold the later parts of an expanded logical volume 2 filesystem. This is much quicker and safer than moving a partition's start point, since from the filesystem's point of view, it's a simple expansion operation.

Another advantage of LVM is that it enables online filesystem resizing. GParted requires that any partitions you modify be unmounted before they're adjusted. Some of the text-mode equivalents don't make this requirement, but some do. Certainly if you need to grow your root (/) filesystem, you pretty much need to do it from an emergency disc. With LVM, you can often make the changes without rebooting, although this feature does rely on filesystem support, so with some filesystems you may still need to reboot. This may be a convenience issue to a home desktop user, but it's much more than that for a big server computer.

One drawback to the LVM approach is that it can create fragmentation. If you do a lot of logical volume juggling, you can end up with a filesystem that's scattered across an entire disk rather than localized, much like a big disk file that's often appended. This will happen only if you make a lot of changes during the LVM's lifetime, though. As you say, there's also a risk that if something goes wrong, a tool like TestDisk will have a harder time recovering a filesystem from a fragmented LVM setup than it would a regular partition. This problem can be mitigated by proper use of backups.

Still, the bottom line is that LVM is more than a tool to increase convenience; it also increases safety of partition/volume adjustments and enables online adjustments that aren't possible with GParted.

----------

