Standard partition vs LVM, which one is better?

When I recently re-installed Fedora, I chose to partition the hard drive manually and anaconda showed me up two options: standard partition and LVM, I wasn’t sure about the latter so I opted by the former.

The question is: Which one is better and why?

1 Like

In my opinion the LVM partition is more usefull cause then after installation you can later change partition sizes and number of partitions easily. In standard partition also you can do resizing, but total number of physical partitions are limited to 4. With LVM you have much greater flexibility.

4 Likes

To add to what @chetankhilosiya said, not only does LVM allow more flexible resizing, but…

  • Partitions can be (in fact, have to be) grown while online, so there’s no need to disrupt other activity while lvresize is doing its thing.
  • That also applies to migration of physical extents with pvmove. (An “extent” is the basis unit of disk space that LVM’s tools work with. On my machines the extent size is 32MB. You can make filesystems any size you want, but volumes (read: “partitions”) will be sized in whole numbers of extents, rounding up automatically.)
  • Multiple physical disk partitions (real partitions), on the same or different physical disks, can all be managed as part of the same Volume Group, and extents laid out among them freely.
  • A logical volume’s extents don’t all have to be on the same partition, nor do they have to be contiguous (in one solid block).

Which means you have cool options like this: Say you have a desktop computer with a single hard disk in it, and you decide to add a second disk for more/faster storage, but keeping the original disk as the boot / root volume. You want your /home partition to take advantage of the space and/or speed of the new disk. You have (at least) these two options, ignoring for now possibilities like RAID, striping, etc…

(NOTE: Don’t take these commands as gospel, they’re off the top of my head and I may have missed something. For Entertainment Purposes Only™.)

# Set the new disk up as Physical Volume
# and add it to the existing Volume Group
sudo pvcreate /dev/sdb1
sudo vgextend vg00 /dev/sdb1

# Option 1: Move your /home volume (lv_home) to the
# new pv, freeing the extents it previously occupied
pvmove -n lv_home /dev/sda1 /dev/sdb1
# Since presumably the new disk is bigger, grow
# lv_home to be 200GB larger, keeping all of the
# extents together on the new PV
lvresize -r -L +200G --alloc contiguous vg00/lv_home

# Option 2: Extend your /home volume to 100G
# of empty space on the new drive, but leave the
# existing extents on the old drive alone.
lvresize -r -l +3125 vg00/lv_home /dev/sdb1

(The -L flag to lvresize specifies a size in bytes (or specified unit), the -l flag specifies a whole number of extents. The critical -r flag tells it to automatically resize the filesystem on that volume to fill the new size — otherwise, you’ll have a larger partition, with the exact same size filesystem on it, and no additional usable space.)

The pvmove-based version will be very slow, it physically has to copy every block from the old drive to the new one. But the lvresize part of the operation will be very quick, no matter which option you take. It basically just involves adjusting some metadata about the size and layout of the logical volume.

No matter which of these options you were to choose, the entire process would be performed online, while /home is not only still mounted, but still usable and able to respond to other requests during the lvm operations. So, yeah, the pvmove would take tens of minutes, if not hours… but who cares? You start it, you go right back to web browsing or writing code or watching movies or whatever, and it gets done when it gets done. No waiting and no hassle.

LVM is pretty frickin’ awesome.

2 Likes