Extend Volumes Non-Destructively

lvextend - a hands-on Linux lab on a real virtual machine.

Grow a logical volume and its filesystem online without unmounting or losing data. Extend the LV by a delta with lvextend -L +512M or fill the group with -l +100%FREE, and use the RHEL 10 flag -r to grow the LV and its filesystem in one step (xfs_growfs for XFS, resize2fs for ext4 by hand). Verify by making lvs and df agree, and remember XFS can only grow, never shrink. Serves EX200 local-storage task 11: extend existing logical volumes.

The web server's data volume hits 100 percent full in the middle of the night. Uploads start failing. The obvious move is a disaster: back off the machine, delete the volume, make a bigger one, and everything on that volume goes with it. But this is a logical volume, and there is spare room left in its volume group. So you do the thing that feels impossible the first time you see it. You make the mounted, in-use volume bigger while it stays mounted and the data stays put.

That move, growing a logical volume and its filesystem online without unmounting and without losing a byte, is EX200 local-storage task 11: extend existing logical volumes. It is the most commonly tested storage task on the exam. By the end of this lesson you will grow a live XFS volume in a single command and prove the data survived.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs shown are from a real RHEL 10 machine (AlmaLinux 10.2) with two spare disks, run as root because storage work needs root. Exact sizes, extent counts, and UUIDs are live values, so yours will read differently. What stays true everywhere is the SHAPE of each command and the rule that XFS can only grow, and those are the lesson.

A logical volume has two layers stacked on top of each other, and both must grow. The bottom layer is the LV itself, the block device, the raw container. On top of it sits a filesystem, XFS or ext4, that formats that space into something you can store files in. Making an LV bigger is really two jobs.

First you lvextend the LV so the block device grows, pulling free space from the volume group. Then you grow the filesystem so it actually uses the new space. Miss the second job and lvs will show a bigger LV while df still shows the old size, because the filesystem never noticed the extra room. On RHEL 10 one flag does both jobs in a single step, and you will meet it in a moment.

The reason this matters is that production volumes are always in use. You cannot take the company database offline to resize its disk, and you certainly cannot destroy and rebuild it. LVM was built so that a volume can grow while it is mounted and serving traffic, with zero downtime and zero risk to the data already there.

The exam models exactly this pressure: it hands you a mounted LV that already contains files and asks you to make it bigger without losing them. Every command in this lesson is safe to run on a live volume. That is the whole point of the tool.

The first way to grow is by a fixed amount. The flag is -L, for size, and the + in front of the number is the most important character in the command. -L +512M ADDS 512 mebibytes to whatever the LV is now. Drop the plus and -L 512M SETS the size to exactly 512M. On a volume already bigger than that, setting a smaller absolute size tries to shrink it, and XFS cannot shrink. The + is the difference between growing and disaster.

Point it at the LV's device path, /dev/vgdata/lvweb, and add half a gibibyte:

lvextend -L +512M /dev/vgdata/lvweb

prompt: [root@servera ~]# answer: lvextend -L +512M /dev/vgdata/lvweb output: Size of logical volume vgdata/lvweb changed from 1.00 GiB (256 extents) to 1.50 GiB (384 extents). hint: The flag is -L, the plus means ADD, the amount is 512M, then the LV path: lvextend -L +512M /dev/vgdata/lvweb

LVM reports the change in two units at once: the LV went from 1.00 GiB to 1.50 GiB, and underneath that, from 256 extents to 384 extents. An extent is LVM's unit of allocation, 4 MiB each by default, so 128 new extents times 4 MiB is the 512M you asked for. The block device is now bigger. But notice what this output does NOT say: it says nothing about the filesystem. Right now df would still show the old size, because you have only grown the container, not the filesystem inside it. That is the trap the next reps close.

Your starting and ending sizes will differ. This machine's lvweb happened to start at exactly 1.00 GiB (256 extents), so adding 512M landed on 1.50 GiB (384 extents). On a differently sized LV the numbers change, but the FORM is fixed: changed from <old> to <new>, always reported in both gibibytes and extents.

Sometimes you do not want a specific amount. You want all of it, every free extent left in the volume group. Counting mebibytes by hand is error-prone, so LVM gives you a percentage form. Note the flag changes from capital -L to lowercase -l: capital -L takes a human size like 512M, lowercase -l takes extents or a percentage.

-l +100%FREE means add one hundred percent of the free extents in the VG. It is the single most typed lvextend on exam day, because 'use the rest of the disk' is a common instruction:

lvextend -l +100%FREE /dev/vgdata/lvweb

prompt: [root@servera ~]# answer: lvextend -l +100%FREE /dev/vgdata/lvweb output: hint: Lowercase -l takes a percentage, +100%FREE means all the group's free extents: lvextend -l +100%FREE /dev/vgdata/lvweb

+100%FREE hands the LV every extent the volume group had left, so there is no leftover space stranded in the VG. Watch the two cases you will confuse under pressure: -L +100M (capital L, a plus, a human size) ADDS 100 mebibytes; -l +100%FREE (lowercase l, a percentage) adds ALL free extents. Same word 'extend', two different flags. When the task says 'use all remaining space', reach for -l +100%FREE. When it names an amount, reach for -L +<size>.

The plus sign is the whole game. lvextend -L +512M ADDS 512M. lvextend -L 512M SETS the LV to exactly 512M, and if the LV is already bigger, LVM tries to shrink it, which for an XFS filesystem means corruption because XFS cannot shrink. Under exam pressure people drop the plus and turn a grow into a shrink. When in doubt, use the +.

Now the flag that saves you a step and saves the exam. Add -r (long form --resizefs) to any lvextend and LVM will, right after growing the LV, detect the filesystem type and call the correct resize tool for you: xfs_growfs for XFS, resize2fs for ext4. One command does both jobs. No second step to forget.

This is how most engineers grow a mounted volume on RHEL 10. Grow the LV and its XFS filesystem together, in place, while it stays mounted:

lvextend -r -L +512M /dev/vgdata/lvweb

prompt: [root@servera ~]# answer: lvextend -r -L +512M /dev/vgdata/lvweb output: Size of logical volume vgdata/lvweb changed from 1.00 GiB (256 extents) to 1.50 GiB (384 extents). Extended file system xfs on vgdata/lvweb. hint: Add -r to the lvextend so it resizes the filesystem too: lvextend -r -L +512M /dev/vgdata/lvweb

Two lines now, and the second one is the payoff. Size of logical volume ... changed from 1.00 GiB ... to 1.50 GiB is the LV growing, exactly as before. But Extended file system xfs on vgdata/lvweb is the part -r added: the XFS filesystem grew to fill the new space in the same breath. No separate xfs_growfs. This is the difference between -r and the plain lvextend from rep one, which grew only the container and left the filesystem behind. If you remember one thing from this lesson, remember -r.

Growing is only half the exam. You have to prove it worked and prove nothing broke. Two checks tell the whole story. lvs shows the LV's new size at the LVM layer, and df -h shows the filesystem's size at the mounted layer. When those two numbers match, the grow was complete: the LV grew AND the filesystem caught up. If lvs is bigger than df, you forgot to grow the filesystem.

Check the mounted filesystem's size after the grow:

df -h /mnt/web

prompt: [root@servera ~]# answer: df -h /mnt/web output: Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgdata-lvweb 1.5G 61M 1.4G 5% /mnt/web hint: df -h shows human-readable sizes; point it at the mount point: df -h /mnt/web

df reports 1.5G for /dev/mapper/vgdata-lvweb, which matches the 1.50 GiB lvs showed. The two layers agree, so the grow is genuinely done, not half-done. The device name is the device-mapper form vgdata-lvweb rather than /dev/vgdata/lvweb, but it is the same volume seen from the mount table. The used space, 61M, is your data, still sitting there untouched inside a now-larger filesystem.

Your exact sizes will differ, and that is fine. The check that matters is not the specific number, it is that the lvs size and the df size AGREE. When they disagree, the LV grew but the filesystem did not, and the fix is xfs_growfs /mnt/web for XFS or resize2fs /dev/vgdata/lvweb for ext4. With -r you never hit that gap, because it grew both at once.

Scaffolding off. No command is printed this time. You have every piece you need.

Before growing the volume, you dropped a marker file named sentinel into /mnt/web. Now the grow is finished and you want to prove, in one command, that the file is still there, that the whole operation was non-destructive. Think about the simplest command that prints the contents of a directory. Point it at the mount point and read the result.

prompt: [root@servera ~]# answer: ls /mnt/web output: sentinel hint: The command that lists a directory's contents is ls, and the directory is the mount point /mnt/web: ls /mnt/web

sentinel. The file you placed before the grow is still there, exactly where you left it, inside a filesystem that is now half a gibibyte bigger. That single line is task 11's proof of safety: the volume grew, the filesystem grew, and not one byte of data moved or vanished. This is why LVM online extension is trusted in production. You grow the disk under a running service and the service never notices, except that it stops running out of room.

You earned this cheat sheet. Every row is a form you just ran or built:

The one thing to burn in for the exam: lvextend -r grows the LV and the filesystem together, so you never leave df behind lvs. And XFS can only GROW, never shrink, so always ADD with the + and never set a smaller absolute size.

Two device-path gotchas that cost points: xfs_growfs takes the MOUNT point (/mnt/web), while resize2fs takes the DEVICE path (/dev/vgdata/lvweb). Mix them up and you get 'is not a mounted XFS filesystem' or 'Bad magic number'. Using -r sidesteps both, because LVM picks the right tool and the right argument for you.

The practice terminal has shown you the whole non-destructive grow: lvextend -L +512M to add a fixed amount, lvextend -l +100%FREE to swallow all the free space, and the RHEL 10 shortcut lvextend -r that grows the LV and its XFS filesystem in a single command. You verified the grow by making lvs and df agree, and you proved the data survived with a sentinel file. Every one of those you typed yourself.

The local-storage module mission is where you run these against a real RHEL 10 machine. A full VM boots for you with two spare disks, a live LVM stack, and a mounted volume that already holds data waiting to be grown. The mission hands you objectives that use exactly what you practiced here: extend a mounted LV, grow its filesystem in place, and prove the files survived. One difference from this lesson: the mission shows no commands. You read the objective, recall the lvextend -r form, and type it. That recall is what makes it stick on exam day.

Finish the other local-storage lessons, then go grow a real machine's volume without losing a byte.

Practice Extend Volumes Non-Destructively in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.