A team asks you to shrink an LVM logical volume holding a 500 GB filesystem down to 200 GB so the freed extents can go to another volume. What do you check first, and what is the correct order of operations?

## Why shrinking is a different animal from growing Growing is additive and safe: new blocks appear past the end of the filesystem, and nothing that already exists moves. Shrinking is destructive by nature. The filesystem must relocate every block and every piece of metadata that currently lives beyond the new boundary, rewrite its allocation structures, and only then can the device underneath be truncated. If the block device is cut first, everything past the cut simply disappears while the filesystem still believes it is there — the result is corruption, discovered later, on data you were not thinking about. ## Step zero: what filesystem is this? ``` lsblk -f /dev/vg0/data blkid /dev/vg0/data ``` The answer decides whether the task is possible at all. **XFS cannot shrink.** This is not a missing flag or a privileged operation — the capability does not exist in xfsprogs or in the kernel, and it has not for the whole life of the filesystem. `xfs_growfs` is grow-only, and there is no `xfs_shrinkfs`. `lvreduce -r` on an XFS volume fails at the `fsadm` stage rather than doing something clever. The only route is data movement: create a new, smaller logical volume, `mkfs.xfs` it, copy the data across, swap the mount, and remove the old volume. On a system where that is the root filesystem, it means a restore rather than a resize. Since XFS is the default on RHEL-family distributions, this comes up often, and "you cannot, here is what I would do instead" is the answer an interviewer is listening for. **ext4 can shrink, offline.** `resize2fs` performs online growth but only offline shrink; on a mounted filesystem it refuses with a message saying the filesystem must be unmounted. So a shrink is a maintenance window, always. ## The ext4 procedure, in order ``` umount /data e2fsck -f /dev/vg0/data # mandatory: resize2fs demands a clean, forced check resize2fs /dev/vg0/data 190G # filesystem first, and undershoot the target lvreduce -L 200G /dev/vg0/data # block device second mount /data df -h /data resize2fs /dev/vg0/data # optional: grow back to fill the 200G volume exactly ``` Two details make this safer. First, shrink the filesystem to a little **less** than the volume's target size. Filesystem blocks and LVM extents are different units and the arithmetic does not land exactly, so a small gap guarantees the volume never ends up smaller than the filesystem. The final no-argument `resize2fs` then expands it back to fill the volume precisely. Second, the shrink can only succeed if the data actually fits — `df` must show less used than the target — and it may take a long time on a full filesystem, because every block above the boundary is physically relocated. ## What lvreduce -r does and does not save you from `lvreduce -r -L 200G /dev/vg0/data` (`--resizefs`) calls `fsadm`, which knows to shrink the filesystem before the volume. It gets the ordering right, which is the most dangerous part, and it will refuse on a filesystem it cannot shrink. What it does not do is make the operation online, and it does not make it reversible. `lvreduce` also prompts before destroying data, and the prompt is not noise — it is the last checkpoint before an irreversible truncation. ## The absolute-versus-relative trap, again `lvreduce -L 200G` sets the size to 200 GB. `lvreduce -L -200G` removes 200 GB, leaving 300 GB. One character separates them and there is no undo. Read the command back before pressing enter, and prefer the form whose result you can state as an absolute number. ## Reversibility and the honest recommendation Restoring a reduced volume to its old size restores the extents, not the data that was cut. Shrinking is the one LVM operation with no safety net, which is why experienced operators avoid needing it: allocate conservatively so growth — which is online, cheap and safe — is the operation you perform, and treat a shrink request as a sign that provisioning was too generous rather than as routine maintenance. When a shrink is genuinely required, take a verified backup first, and if the freed space is only wanted for another volume, ask whether adding a disk is cheaper than an outage plus a risk. ## What to say when the answer is no On XFS, the professional answer names the constraint, the workaround and its cost: no shrink support exists; the workaround is create-copy-swap onto a smaller volume; the cost is an outage proportional to the data volume plus enough free space in the group to hold both copies at once. Interviewers ask this precisely because a candidate who has only grown volumes assumes symmetry.