ext4, end to end: create, reserve, grow, shrink
ext4 is the default for a reason. It’s boring, it’s well understood, and it handles almost everything you’ll throw at it. The videos show the commands; this page explains why they work.
The model is the usual one: disk → partition → filesystem. Everything below runs on a disposable 2 GB scratch disk, never on the machine you depend on.
Create it
sudo parted -s /dev/sdb mklabel gpt
sudo parted -s /dev/sdb mkpart data ext4 1MiB 1GiB
sudo mkfs.ext4 -F -L data /dev/sdb1
sudo mkdir -p /mnt/fslab
sudo mount /dev/sdb1 /mnt/fslab
-L data sets the label; -F forces the creation on a partition that may still
carry a signature. The proof is not the command, it is the round-trip: write a
file, unmount, mount again, read it back.
echo 'hello from ext4' | sudo tee /mnt/fslab/hello.txt
sudo umount /mnt/fslab
sudo mount /dev/sdb1 /mnt/fslab
sudo cat /mnt/fslab/hello.txt
Then inspect it: sudo dumpe2fs -h /dev/sdb1, sudo blkid /dev/sdb1,
df -h /mnt/fslab.
That is where the geometry, UUID and free space come from.
The 5% root reservation
ext4 reserves 5% of its blocks for root by default. That is a safety net for
/: when a user fills the disk, root can still log in and fix it. On a data
disk it is often wasted space.
sudo dumpe2fs -h /dev/sdb1 | grep 'Reserved block count' # 13094 on a 1 GB fs
sudo tune2fs -m 0 /dev/sdb1
sudo dumpe2fs -h /dev/sdb1 | grep 'Reserved block count' # 0
Do not do this on a real root filesystem without understanding the recovery trade-off. On a data disk it is a one-line win.
Grow it
A 1 GB partition on a 2 GB disk leaves free space to grow into. Grow the partition first, then the filesystem:
sudo growpart /dev/sdb 1
sudo resize2fs /dev/sdb1
df -h /mnt/fslab
resize2fs can grow ext4 online (mounted). That is the common case: enlarge
the disk, grow the partition, grow the filesystem, no downtime.
growpart is not always installed: on Debian/Ubuntu it comes from
cloud-guest-utils, on the RHEL family from cloud-utils-growpart.
Shrink it
Shrinking is the reverse order, and it is offline:
sudo umount /mnt/fslab
sudo e2fsck -f -p /dev/sdb1 # preen: only safe fixes
sudo resize2fs /dev/sdb1 900M # smaller than the target partition
sudo parted /dev/sdb resizepart 1 1GiB # asks for confirmation
sudo resize2fs /dev/sdb1 # grow back to fill the partition
sudo mount /dev/sdb1 /mnt/fslab
e2fsck -fis required before an offline shrink.- Shrink the filesystem first, then the partition. Shrinking the partition first can cut off filesystem blocks.
- Shrink with margin (900M here), then grow the filesystem back to fill the partition. That way you never have to calculate the exact block count.
partedasks for confirmation when shrinking. In a script you have to answer it (Yes), and some versions abort instead of continuing — test before you automate it.- Never shrink a mounted filesystem; never shrink the host’s root.
Check and repair
e2fsck is the offline checker. Run it on an unmounted filesystem; -p fixes
only what is safe to fix automatically, while -y answers yes to everything, so
use it knowingly. If the primary superblock is damaged, ext4 keeps backups:
sudo dumpe2fs /dev/sdb1 | grep -i superblock shows where they are, and
sudo e2fsck -b 32768 /dev/sdb1 uses the classic first backup.
What to remember
- ext4 is the safe default; it grows online and shrinks offline.
- The 5% reservation is for
/, not for every data disk. - The order is always: grow the container, then the filesystem; shrink the filesystem (with margin), then the container, then grow the filesystem to fit.
- Snapshots are not native to ext4 — use LVM if you need them. A snapshot is not a backup.
Part of Filesystems, end to end.