Reclaim hard-drive space with LVM

Hard drive image

Photo by Frank R @

LVM is a tool for logical volume management which includes allocating disks, striping, mirroring and resizing logical volumes. It is commonly used on Fedora installations (prior to BTRFS as default it was LVM+Ext4). But have you ever started up your system to find out that Gnome just said the home volume is almost out of space! Luckily, there is likely some space sitting around in another volume, unused and ready to re-alocate. Here’s how to reclaim hard-drive space with LVM.

The key to easily re-alocate space between volumes is the Logical Volume Manager (LVM). Fedora 32 and before use LVM to divide disk space by default. This technology is similar to standard hard-drive partitions, but LVM is a lot more flexible. LVM enables not only flexible volume size management, but also advanced capabilities such as read-write snapshots, striping or mirroring data across multiple drives, using a high-speed drive as a cache for a slower drive, and much more. All of these advanced options can get a bit overwhelming, but resizing a volume is straight-forward.

LVM basics

The volume group serves as the main container in the LVM system. By default Fedora only defines a single volume group, but there can be as many as needed. Actual hard-drive and hard-drive partitions are added to the volume group as physical volumes. Physical volumes add available free space to the volume group. A typical Fedora install has one formatted boot partition, and the rest of the drive is a partition configured as an LVM physical volume.

Out of this pool of available space, the volume group allocates one or more logical volumes. These volumes are similar to hard-drive partitions, but without the limitation of contiguous space on the disk. LVM logical volumes can even span multiple devices! Just like hard-drive partitions, logical volumes have a defined size and can contain any filesystem which can then be mounted to specific directories.

What’s needed

Confirm the system uses LVM with the gnome-disks application, and make sure there is free space available in some other volume. Without space to reclaim from another volume, this guide isn’t useful. A Fedora live CD/USB is also needed. Any file system that needs to shrink must be unmounted. Running from a live image allows all the volumes on the hard-disk to remain unmounted, even important directories like / and /home.

Use gnome-disks to verify free space.
Use gnome-disks to verify free space

A word of warning

No data should be lost by following this guide, but it does muck around with some very low-level and powerful commands. One mistake could destroy all data on the hard-drive. So backup all the data on the disk first!

Resizing LVM volumes

To begin, boot the Fedora live image and select Try Fedora at the dialog. Next, use the Run Command to launch the blivet-gui application (accessible by pressing Alt-F2, typing blivet-gui, then pressing enter). Select the volume group on the left under LVM. The logical volumes are on the right.

Explore logical volumes in blivet gui.
Explore logical volumes in blivet-gui

The logical volume labels consist of both the volume group name and the logical volume name. In the example, the volume group is “fedora_localhost-live” and there are “home”, “root”, and “swap” logical volumes allocated. To find the full volume, select each one, click on the gear icon, and choose resize. The slider in the resize dialog indicates the allowable sizes for the volume. The minimum value on the left is the space already in use within the file system, so this is the minimum possible volume size (without deleting data). The maximum value on the right is the greatest size the volume can have based on available free space in the volume group.

Use the resize dialog in blivet-gui to set the new volume sizes.
Resize dialog in blivet-gui

A grayed out resize option means the volume is full and there is no free space in the volume group. It’s time to change that! Look through all of the volumes to find one with plenty of extra space, like in the screenshot above. Move the slider to the left to set the new size. Free up enough space to be useful for the full volume, but still leave plenty of space for future data growth. Otherwise, this volume will be the next to fill up.

Click resize and note that a new item appears in the volume listing: free space. Now select the full volume that started this whole endeavor, and move the slider all the way to the right. Press resize and marvel at the new improved volume layout. However, nothing has changed on the hard drive yet. Click on the check-mark to commit the changes to disk.

Review the changes in blivet-gui and then accept to reclaim hard-drive space.
Review changes in blivet-gui

Review the summary of the changes, and if everything looks right, click Ok to proceed. Wait for blivet-gui to finish. Now reboot back into the main Fedora install and enjoy all the new space in the previously full volume.

Planning for the future

It is challenging to know how much space any particular volume will need in the future. Instead of immediately allocating all available free space, consider leaving it free in the volume group. In fact, Fedora Server reserves space in the volume group by default. Extending a volume is possible while it is online and in use. No live image or reboot needed. When a volume is almost full, easily extend the volume using part of the available free space and keep working. Unfortunately the default disk manager, gnome-disks, does not support LVM volume resizing, so install blivet-gui for a graphical management tool. Alternately, there is a simple terminal command to extend a volume:

lvresize -r -L +1G /dev/fedora_localhost-live/root 


Reclaiming hard-drive space with LVM just scratches the surface of LVM capabilities. Most people, especially on the desktop, probably don’t need the more advanced features. However, LVM is there when the need arises, though it can get a bit complex to implement. BTRFS is the default filesystem, without LVM, starting with Fedora 33. BTRFS can be easier to manage while still flexible enough for most common usages. Check out the recent Fedora Magazine articles on BTRFS to learn more.

FAQs and Guides For System Administrators Using Software


  1. Esc

    Thank You

  2. Sergey


    Any file system that needs to shrink must be unmounted.
    and XFS ?

  3. ooh – such perfect timing – I’m just now trying to figure out if it’s safe to downsize my root partition so my home partition can grow.

  4. Doug

    Thanks for listening to my article suggestion. Having a ~120 GB SSD means that, using the automatic setup, you end up with a very small /home partition. This is useful to tweak it after the installation is completed, although you can also use Anaconda’s custom partitioning functionality to customize the default setup yourself (it’s not so difficult).

    • It was perfect for me to pick up! I am a big LVM fan and I was happy to have a way to contribute to Fedora. Definitely a great idea (even if BTRFS is the new default 😁).

  5. Cornel Panceac

    How can i shrink the volume group so that i can allocate more storage space to the other, more storage-hungry OS?

    • It is definitely possible to shrink the volume group, but it is a bit more complex and a lot more manual. My untested and unverified approach would go something like:

      Reduce logical volumes (similar to the article) to add free space to the volume group
      Use pvresize to shrink the physical volume slightly less the intended size (and hope that extents aren’t already allocated past the new size, pvresize should fail to change the size in this case).
      Resize the underlying partition
      Use pvresize again, but do not specify a size so that it fills up to exactly the new size of the partition
      Add a new partition to the now free space on the hard disk.

      There is definitely a decent chance to get various steps wrong here, so definitely make sure there are backups before attempting.

      Doing 2 calls to pvresize isn’t strictly necessary, but with only 1 call the size calculation must be exactly right. This is challenging because the units are not always obvious (bytes, blocks, etc). That is why it is best to shrink a little more than necessary with the first pvresize to provide a bit of buffer, and then allow the second pvresize (after shrinking the partition) to calculate the precise values.

      Also if extents have been allocated past the end of where the desired pv size would be, then some clever shuffling of extent ranges with a combination of “lvdisplay -m” and “pvmove ..” will be necessary to relocate the extents into an earlier part of the physical volume.

  6. Guus

    I currently have LVM + ext4 and am still running F32, but I want to get to F33 and if possible convert to btrfs. So I wonder, does LVM play any roll at all with btrfs? Or is the roll that LVM plays now, being taken over by btrfs?

    • It’s definitely possible to have BTRFS on a LVM logical volume, and there are some reasons you may want to go with that approach. However, there are definitely some trade offs. For the most common use cases, especially for desktop, using BTRFS directly on the harddrive probably gives most of features you might want. In particular, subvolumes allow for easy and fast snapshot creation for backups. However, with BTRFS you don’t have some of the features that LVM provides, such as a thinly provisioned volumes for use by different filesystems or direct block device volumes (which are nice for virtual machines). Note that with BTRFS copy on write built in capabilities, and read-write subvolume snapshots, the thinly provisioned use case is completely covered as long as you want the volumes (really subvolumes in BTRFS case) to be BTRFS and not some other filesystem.

      So really you have to decide what your needs are. Most likely reformatting the disk and using BTRFS directly makes sense if you want easy subvolume snapshot functionality and to play around with a new modern filesystem.

      • Guus

        Thank you for your reply. I get that it is my choice, but I don’t have a particular good feeling about the difference yet. My suspicion is that more people would like to know about the differences. Do you think a comparion between the two variants of using btrfs is possible?

        Another point is, up to now, I had never heard of thin provisioning. I don’t think that is an issue for me. I do however, sometimes use other filesystems. If I do, does btrfs constrain me to use physical partitions?

        I apologize. I have been using Linux for a long time (94 – 98 + 2002 – now) but I am not an advanced user when it comes to storage space. The most advanced I got was repairing a partition I had accidentally removed and that made me pretty anxious, working with fdisk on byte level.

        So, if you ever feel the need to use your knowledge to compare btrfs with or without LVM, with different use cases (workstation, server), I would really like that.

  7. Stephen Brown

    There was a recent article titled “Friends Don’t let Friends Use BTRS”, which has somehow, mysteriously disappeared. from this address

    While there are some great wins wrt using BTRS, there were two takeaways from this article, that I noted.

    Lousy database performance. Which the article attributes to its ‘copy on write’ features. The author did extensive testing across a number of applications and it most definitely is that. I use ‘cow’ a lot. All of my kvm machines are ‘cow2’ disks and it does slow things down. But I want that sparse disk space capability that ‘cow2’ provides so I live with it.
    Data recovery and or data corruption is more likely to occur with btrs than ext4, lets say. File systems like XFS are light years ahead of BTRS wrt this.

    I use LVM a lot. My biggest complaint with LVM is that it’s not so forgiving wrt shrinking volumes. And I really hate the fact that you can’t change volume names and get away with it, if its a volume that your root file system resides on. So unless you know how to rebuild all of that device ID stuff within grub2 and initramfs, don’t even think about it.

    I’m certain that I’m going to waste more disk space with LVM than with BTRS and each year about this time, I’m going to burn incense and wail about it. But in the end, I’ll take all of those file recovery and data recovery capabilities inherent in EXT4 and LVM systems than chance some data corruption with BTRS.

  8. Patrice

    Nice, but funnily anachronistic on Fedora Magazine since BTRFS is the new filesystem on Fedora 33.
    I’d like to see some how-to for BTRFS: what’s the benefit, how to manage it and how to make backups.

    I’m on Fedora 33 but still using the same LVM+Ext4 filesystem until I get more information on BTRFS, specifically how to manage it for simple day-to-day use and how to perform backups.

    • It did seem a bit late to the party to write the LVM article right after Fedora 33 came out with a default filesystem of BTRFS. However, I realized that is only for the desktop variants, LVM+ext4 is still the default on the server. Also, many are probably in the same boat as you (and me) if you just upgrade from previous releases. I spent some time considering switching on my desktop install to BTRFS since I was doing a clean install anyway. Ultimately I decided to stick with LVM+ext4 because I had already setup caching volumes, thin pools, and I didn’t necessarily want to wipe and restore my home volume. I am considering BTRFS on my laptop though, if nothing else than for the learning experience.

  9. Riley

    Thanks so much for this guide. It was super helpful!

    Years ago I made my laptop’s root partition smaller, so I’d have more space in my home partition. But when Flatpak became a thing, it started eating up space in my root folder. So much so, that I didn’t have enough room to download and install new versions of Fedora.

    I was able to follow this simple guide and fix the issue. Now my laptop is running the latest and greatest Fedora.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions