LPIC-2 Filesystem Maintenance and udev Device Management

Advanced35 min7 steps

What you'll learn

Pick the right ext-family tool (tune2fs, dumpe2fs, e2fsck, resize2fs) for a given maintenance job
Inspect, grow, and repair an XFS filesystem — and explain why XFS can never shrink
Apply the one safety rule that prevents most self-inflicted corruption: never check or repair a mounted filesystem
Back up and restore the right way per filesystem type (dump/restore vs xfsdump/xfsrestore)
Write a udev rule for a stable device name and make it take effect without a reboot

Why filesystems need maintenance at all
Frame the toolbox: a filesystem is a database on disk, and like any database it gets tuned, checked, grown, and backed up.
A filesystem isn't just "where files live" — it's a bookkeeping database the kernel writes to disk: which blocks are free, which belong to which file, when each was last touched. That ledger drifts. Disks fill up and need to grow. A power cut can leave the ledger half-written. A label needs changing so scripts don't depend on a fragile device name.
Think of the filesystem as the card catalog in a library. The books (your data) are on the shelves, but the catalog is what lets anyone find them. Maintenance is catalog work: re-checking entries that got scrambled (e2fsck/xfs_repair), adding more drawers when the catalog outgrows itself (resize2fs/xfs_growfs), relabeling a drawer (tune2fs/xfs_admin), and photocopying the whole thing for safekeeping (dump/xfsdump).
LPIC-2 splits this into two filesystem families with parallel-but-different tools, plus udev, the subsystem that decides what your devices are even called. We'll take them in that order.
Why it matters
The exam — and real on-call work — lives in the gap between the families. The ext tools and the XFS tools do the same jobs with different names and different limits. Knowing that resize2fs can shrink but xfs_growfs cannot is exactly the kind of distinction that separates a recovered outage from a corrupted volume.
The ext family: tune2fs, dumpe2fs, e2fsck, resize2fs
Map each ext-family tool to its job and read what its output is telling you.
Every ext2/3/4 filesystem keeps its master record in the superblock — block counts, the label, the UUID, mount counters, and feature flags. Four tools cluster around it:
- `dumpe2fs` — read the superblock (diagnostics, no changes)
- `tune2fs` — tune parameters in the superblock (label, reserved blocks, fsck schedule)
- `e2fsck` — check and repair the structure
- `resize2fs` — grow or shrink the filesystem
Start by reading. tune2fs -l prints the superblock as a clean summary:
Example — not runnable on your lab box
```
$ sudo tune2fs -l /dev/sdb1
```
```
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name:   data
Filesystem UUID:          7d3a1f2c-...-9b04
Filesystem state:         clean
Filesystem features:      has_journal ext_attr resize_inode dir_index
Block count:              2621440
Reserved block count:     131072
Last checked:             Mon Jun 23 09:14:02 2026
Mount count:              7
```
-l
List the contents of the superblock as a key/value report — read-only, the safe way to inspect.
`Filesystem state: clean` means the journal was flushed and the fs was unmounted properly — no repair needed. `Reserved block count: 131072` is the 5% root keeps so a full disk can't lock out admins. `Mount count: 7` is how many times it's mounted since the last check; tune2fs can tie a forced fsck to that counter. The Filesystem volume name is the label scripts and /etc/fstab can reference instead of a device path.
Now change something. The most common tune2fs job is setting a label so fstab and mounts don't hardcode /dev/sdb1 (which can move when disks are added):
Example — not runnable on your lab box
```
$ sudo tune2fs -L appdata /dev/sdb1
```
```
tune2fs 1.46.5 (30-Dec-2021)
```
-L
Set the volume LABEL. Then mount by LABEL=appdata instead of a device path.
-m
Set the reserved-block PERCENTAGE (e.g. -m 1 frees space on a big data disk that has no root processes).
-c
Set the max mount COUNT before a forced fsck (-c 0 disables count-based checks).
Near-silent output (just the version banner) means success. The write lands in the superblock, so a later tune2fs -l would show Filesystem volume name: appdata. tune2fs edits metadata about the filesystem; it never touches your files.
dumpe2fs vs tune2fs -l
dumpe2fs prints the superblock plus every block-group descriptor — far more detail, good for forensics on a damaged fs. tune2fs -l shows just the superblock summary. For a quick label/UUID/state check, reach for tune2fs -l; for deep structure, dumpe2fs.
Example — not runnable on your lab box
```
$ sudo resize2fs /dev/sdb1
```
```
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/sdb1 to 3932160 (4k) blocks.
The filesystem on /dev/sdb1 is now 3932160 (4k) blocks long.
```
(no size)
Grow the filesystem to fill the whole underlying partition/LV.
20G
Resize to an explicit size, e.g. resize2fs /dev/sdb1 20G — this is how you SHRINK.
ext supports both directions. Growing can happen on a mounted (online) filesystem. Shrinking must be done offline (unmounted), and you must shrink the filesystem before shrinking the partition/LV underneath it, or you cut off live data. The order is the whole game: shrink fs → shrink container; grow container → grow fs.
Check yourself
You need to change an ext4 filesystem's label without unmounting it and without disturbing any files. Which tool do you reach for?
The XFS family: xfs_info, xfs_admin, xfs_growfs, xfs_repair
Use the XFS-specific toolset and internalize its one hard limit — XFS grows but never shrinks.
XFS is the default on RHEL/CentOS and many storage servers, and its tools are a separate vocabulary — none of the e2* commands work on it. The parallels:
- `xfs_info` ≈ dumpe2fs/tune2fs -l (read geometry: block size, AG count)
- `xfs_admin` ≈ tune2fs (set label and UUID)
- `xfs_growfs` ≈ resize2fs — but grow-only
- `xfs_repair` ≈ e2fsck (check and repair)
xfs_info reads the geometry of a mounted XFS by mountpoint:
Example — not runnable on your lab box
```
$ sudo xfs_info /data
```
```
meta-data=/dev/sdc1   isize=512    agcount=4, agsize=655360 blks
data     =            bsize=4096   blocks=2621440, imaxpct=25
naming   =version 2  bsize=4096   ascii-ci=0, ftype=1
log      =internal log bsize=4096   blocks=2560, version=2
realtime =none        extsz=4096   blocks=0, rtextents=0
```
/data
Pass the MOUNTPOINT (or device). xfs_info reads an active filesystem — no unmount needed to inspect.
`agcount=4` is the number of allocation groups — XFS splits a volume into parallel regions for concurrent I/O. `bsize=4096` is the block size. `blocks=2621440` × 4096 ≈ 10 GiB of capacity. This is your XFS equivalent of reading the ext superblock — geometry first, before you touch anything.
Example — not runnable on your lab box
```
$ sudo xfs_growfs /data
```
```
data blocks changed from 2621440 to 3932160
```
/data
Grow the XFS mounted here to fill the (already-enlarged) underlying device. Done ONLINE, while mounted.
xfs_growfs extends the filesystem onto space you've already added to the partition or LV beneath it — and it does so while mounted, with no downtime. The block count jumps to match the new container. There is deliberately no shrink option: XFS's on-disk layout spreads metadata across the whole volume, so the space at the end can't simply be lopped off.
You cannot shrink XFS — period
There is no xfs_shrinkfs, and no flag to xfs_growfs that makes it smaller. If a volume must get smaller, the only path is: back up (xfsdump), recreate a smaller XFS with mkfs.xfs, restore (xfsrestore). Provision XFS volumes conservatively — over-allocating is far easier to fix than under-allocating.
Example — not runnable on your lab box
```
$ sudo xfs_admin -L appdata /dev/sdc1
```
```
writing all SBs
new label = "appdata"
```
-L
Set the XFS label (the tune2fs -L equivalent).
-U
Set or generate the UUID (e.g. -U generate after cloning a disk so two volumes don't share a UUID).
xfs_admin is XFS's tune2fs. Setting a label is generally fine on a mounted volume, but changing the UUID requires the filesystem to be unmounted — XFS won't rewrite that identity field while it's in use. "writing all SBs" confirms the superblocks were updated.
Check yourself
Your XFS /data volume was over-provisioned and you need to reclaim 20 GB. Which command shrinks it in place?
The safety rule: never check or repair a mounted filesystem
Internalize the single rule that prevents the most catastrophic self-inflicted corruption.
e2fsck and xfs_repair both work by reading the filesystem's structures, deciding what's inconsistent, and rewriting metadata to fix it. They assume the on-disk picture is static while they work.
Now imagine the kernel has that same filesystem mounted: it's caching metadata in RAM and writing its own updates back to disk. The repair tool and the kernel are now two editors fighting over the same document with no coordination. The repair tool "fixes" a block; the kernel flushes a stale cached copy over the top; the result is a filesystem more broken than when you started — sometimes unrecoverably.
The rule: run `e2fsck` and `xfs_repair` only on an UNMOUNTED filesystem. Confirm the state first, every time.
```
$ findmnt /dev/sdb1
```
```
TARGET SOURCE    FSTYPE OPTIONS
/mnt   /dev/sdb1 ext4   rw,relatime
```
<device>
Show where (and whether) a device is mounted. Empty output / non-zero exit = NOT mounted = safe to repair.
Output here means /dev/sdb1 is mounted at /mnt — so it is not safe to fsck yet. If findmnt printed nothing and returned non-zero, the device would be unmounted and clear to check. Always run this check before the repair, not after.
```
$ sudo umount /mnt && sudo e2fsck -f /dev/sdb1
```
```
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb1: clean, 312/655360 files, 84120/2621440 blocks
```
-f
FORCE a full check even if the superblock says 'clean' — e2fsck skips clean filesystems by default.
-p
Preen: auto-fix safe problems with no prompts (what boot scripts use).
-n
Answer 'no' to all — a read-only dry run that reports problems without changing anything.
Unmount first, then check. The five passes walk inodes → directories → connectivity → link counts → group summaries. A clean run ends with the files/blocks tally. For XFS the equivalent is xfs_repair /dev/sdc1 (also unmounted); xfs_repair -n is its read-only dry run.
The root filesystem can't be unmounted while running
You can't umount /. To fsck the root filesystem you boot from rescue/installation media (or trigger a check at the next boot). The unmount rule still holds — you just satisfy it by running the repair from outside the booted system.
The trap: fsck on a live volume
Running e2fsck /dev/sda1 (or xfs_repair) while it's still mounted is the classic disaster. It may appear to run, but you've set two writers loose on the same metadata. Unmount, verify with `findmnt`, then repair — in that order, no exceptions.
Check yourself
Before running e2fsck or xfs_repair on a data volume, what state must the filesystem be in to avoid corruption?
Backups per filesystem type: dump/restore vs xfsdump/xfsrestore
Choose the backup toolchain that matches the filesystem and understand why they aren't interchangeable.
Filesystem-aware backup tools beat plain cp because they capture metadata and structure (ownership, ACLs, sparse files, hard links) and support incremental levels keyed to dump time. But the tool must match the filesystem — each understands only its own on-disk format:
- ext2/3/4 → `dump` (back up) / `restore` (recover)
- XFS → `xfsdump` (back up) / `xfsrestore` (recover)
They are not interchangeable: dump cannot read XFS, and xfsdump cannot read ext. Pick by the source filesystem.
Example — not runnable on your lab box
```
$ sudo dump -0u -f /backup/sdb1.dump /dev/sdb1
```
```
DUMP: Date of this level 0 dump: Tue Jun 23 10:02:11 2026
DUMP: Dumping /dev/sdb1 (/mnt) to /backup/sdb1.dump
DUMP: estimated 328612 blocks.
DUMP: DUMP IS DONE
```
-0
Dump LEVEL: 0 = full backup. 1-9 = incremental (only files changed since the last lower-numbered dump).
-u
Update /etc/dumpdates so the next incremental knows what 'since last time' means.
-f
Output FILE (or device/tape) to write the dump to.
This is a level-0 (full) dump of the ext filesystem. The -u flag records the timestamp in /etc/dumpdates, so a later dump -1u ... backs up only what changed since this full — the foundation of an incremental rotation. Recover later with restore -rf /backup/sdb1.dump into an empty target filesystem.
Example — not runnable on your lab box
```
$ sudo xfsdump -l 0 -f /backup/data.xfsdump /data
```
```
xfsdump: using file dump (drive_simple) strategy
xfsdump: level 0 dump of host:/data
xfsdump: dump complete: 41 seconds
xfsdump: Dump Status: SUCCESS
```
-l 0
Dump LEVEL (0 = full, 1-9 = incremental) — same model as dump, different flag syntax.
-f
Destination file, device, or tape.
The XFS equivalent, taken by mountpoint (/data). Same level-0/incremental concept, XFS-native format. Restore with xfsrestore -f /backup/data.xfsdump /data. Note the symmetry: same idea as dump, completely different tool — because the on-disk format it reads is different.
Why not just tar everything?
tar/rsync are filesystem-agnostic and fine for files, but they don't natively model dump-level incrementals or every low-level attribute the way dump/xfsdump do. For LPIC-2, know the pairing: ext ↔ dump/restore, XFS ↔ xfsdump/xfsrestore.
Check yourself
You're backing up an XFS-formatted /data volume and want a native, level-aware backup. Which command do you use?
udev: stable device names and live reloads
Write a udev rule that gives a device a predictable name, then make it take effect without rebooting.
Device names like /dev/sdb are not stable: plug a USB disk in first and it might become /dev/sda, bumping your real data disk to /dev/sdb. Hardcoding those names in scripts or fstab is a time bomb.
udev is the userspace daemon that manages /dev. When the kernel detects a device, udev applies rules in /etc/udev/rules.d/*.rules to decide its name, ownership, permissions, and symlinks. Think of udev as a valet with a guest list: it matches a car's plate (a stable attribute like a serial number) and always parks it in the same numbered spot (a fixed symlink), no matter what order cars arrive.
First, find a stable attribute to match on with udevadm info:
Example — not runnable on your lab box
```
$ udevadm info -q property -n /dev/sdb
```
```
DEVNAME=/dev/sdb
ID_SERIAL=Samsung_T7_S5XYZ123
ID_BUS=usb
ID_FS_TYPE=ext4
DEVPATH=/devices/pci0000:00/.../block/sdb
```
-q property
QUERY just the device's properties (the key=value pairs udev rules can match on).
-n /dev/sdb
Identify the device by its NODE path. (-p takes a sysfs path instead.)
`ID_SERIAL=Samsung_T7_S5XYZ123` is the gold here — a value that follows this specific disk regardless of which /dev/sd? letter it lands on. A rule that matches on the serial gives this exact disk a permanent name. (Use udevadm info -a -n /dev/sdb to see the full attribute walk usable in rules.)
Example — not runnable on your lab box
```
$ echo 'SUBSYSTEM=="block", ENV{ID_SERIAL}=="Samsung_T7_S5XYZ123", SYMLINK+="backupdisk"' | sudo tee /etc/udev/rules.d/99-backupdisk.rules
```
```
SUBSYSTEM=="block", ENV{ID_SERIAL}=="Samsung_T7_S5XYZ123", SYMLINK+="backupdisk"
```
==
MATCH operator: this key must equal this value for the rule to fire.
+=
ASSIGN-add operator: append to a list (here, add a symlink) rather than overwrite.
99-
Filename number = ordering. Higher numbers run later; site rules conventionally use high numbers like 99-.
This rule says: for any block device whose serial matches, create a stable symlink `/dev/backupdisk` pointing at whatever /dev/sd? it currently is. Now scripts and fstab can reference /dev/backupdisk forever. You could also add OWNER=, GROUP=, or MODE="0660" here to fix permissions on the device node.
The #1 udev trap: editing a rule and expecting it to just work
udev does not re-read /etc/udev/rules.d/ automatically when you save a file. Your perfect new rule sits inert until you tell the daemon to reload AND re-evaluate existing devices. People edit a rule, see no /dev/backupdisk, and assume the rule is wrong — when it was never loaded. Two commands fix this, and you need both.
Example — not runnable on your lab box
```
$ sudo udevadm control --reload && sudo udevadm trigger
```
control --reload
Tell the running udev daemon to re-read the rules files from disk (loads your new/edited rule).
trigger
Re-fire events for already-present devices so the freshly-loaded rules are APPLIED to them now.
--reload loads the rule; trigger re-runs device events so it actually applies to hardware that's already plugged in (otherwise the rule would only affect the next hotplug). Silent success. After this, ls -l /dev/backupdisk should show the new symlink. Reload-then-trigger is the udev muscle memory to build.
Check yourself
You edited a file in /etc/udev/rules.d/ but the new device symlink never appears. After 'udevadm control --reload', which second command actually applies the rule to the already-connected device?
Try it in your live terminal
Run safe, read-only versions of every inspection move on the real sandbox to your right.
You have a real root shell. These commands are all read-only — they inspect, they never modify, fsck, or unmount anything. Run them in order to practice the inspection half of each skill; the modifying half (resize, repair, write a rule) is what you'd do once inspection tells you it's safe.
```
$ findmnt /
```
What is your root filesystem and what type is it? Note the FSTYPE column — that's what decides whether you'd reach for the ext tools or the XFS tools.
```
$ sudo xfs_info / 2>/dev/null || sudo tune2fs -l $(findmnt -no SOURCE /) | head
```
Read your root filesystem's geometry the right way for its type: xfs_info if it's XFS, otherwise the ext superblock via tune2fs -l. One of the two branches runs depending on what findmnt showed above.
```
$ udevadm info -q property -n /dev/sda 2>/dev/null | head
```
Inspect a real block device's udev properties. Look for an ID_SERIAL or similar stable attribute — that's what a naming rule would match on. (Adjust the device if /dev/sda isn't present.)
Example — not runnable on your lab box
```
$ ls /etc/udev/rules.d/
```
See the custom udev rules already on this system. These are the files udevadm control --reload re-reads when a rule changes.

Recap

The ext and XFS families do the same jobs with different tools — and different limits. The killer asymmetry: ext can shrink, XFS can only grow.
Never run `e2fsck` or `xfs_repair` on a mounted filesystem. Verify with findmnt, unmount, then repair — a live repair fights the kernel and corrupts data.
Match the backup tool to the filesystem: dump/restore for ext, xfsdump/xfsrestore for XFS — they only read their own on-disk format.
udev rules in /etc/udev/rules.d/ give devices stable names by matching a fixed attribute (like a serial). After editing one, `udevadm control --reload` then `udevadm trigger` — both, or it won't apply.

ext tool ↔ XFS equivalent
Job	ext (ext2/3/4)	XFS	Key difference
Inspect / read geometry	`dumpe2fs`, `tune2fs -l`	`xfs_info`	Both read-only; safe while mounted
Tune label / UUID	`tune2fs -L/-U`	`xfs_admin -L/-U`	UUID change needs unmount on both
Grow	`resize2fs` (online ok)	`xfs_growfs` (online ok)	Both grow live
Shrink	`resize2fs <size>` (offline)	not possible	XFS can never shrink — backup+recreate
Check / repair	`e2fsck -f`	`xfs_repair`	Must be UNMOUNTED on both
Backup / restore	`dump` / `restore`	`xfsdump` / `xfsrestore`	Not interchangeable across families

LPIC-2 Filesystem Maintenance and udev Device Management

Why filesystems need maintenance at all

The ext family: tune2fs, dumpe2fs, e2fsck, resize2fs

The XFS family: xfs_info, xfs_admin, xfs_growfs, xfs_repair

The safety rule: never check or repair a mounted filesystem

Backups per filesystem type: dump/restore vs xfsdump/xfsrestore

udev: stable device names and live reloads

Try it in your live terminal