RHEL Storage, XFS, ext4 and Mount Operations

Anil Jalela · Published Sep 3, 2026 · 9 min read

Storage commands can destroy data faster than most administration tools. Device names such as /dev/sdb are observations, not durable identities: discovery order can change after reboot or hardware work. Before partitioning, formatting, repairing or mounting, map the exact device by size, model, serial, WWN, path, filesystem signature and application ownership. A filesystem repair tool is not a substitute for a recoverable backup.

Separate device, partition, filesystem and mount layers

A disk or LUN presents blocks. A partition table may divide them. LVM or RAID may add another mapping. A filesystem organizes files, and a mount attaches that filesystem to the namespace. The mountpoint directory can contain hidden underlying files when another filesystem is mounted over it. Capture every layer before change.

XFS is the normal RHEL default and supports online growth but not shrinking. ext4 has different tooling and can support offline shrink under controlled conditions. Select based on supported workload and recovery requirements, not because one format was familiar on an earlier system.

Resolve the complete storage path

Create and persist a lab filesystem safely

1. Resolve the exact empty lab device. Verify it through independent identity fields and confirm no holders, signatures or mounts.
2. Back up metadata and obtain authorization. Formatting is destructive even when the device name looks new.
3. Create the reviewed layout. Use GPT and alignment suitable for the platform; reread the table and inspect.
4. Create the selected filesystem. Use XFS or ext4 defaults unless a tested requirement justifies options.
5. Mount and set ownership. Use a dedicated mountpoint and application-specific access, not broad world write.
6. Persist by UUID. Add a reviewed fstab entry, run findmnt --verify, unmount/remount and test an approved reboot.

Inventory filesystems and mount state

lsblk -e7 -o NAME,PATH,TYPE,SIZE,MODEL,SERIAL,WWN,FSTYPE,UUID,MOUNTPOINTS
blkid
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
findmnt -T /var
df -hT
df -ih
du -x -h --max-depth=1 /var | sort -h
lsof +L1
findmnt --verify
xfs_info /mountpoint
tune2fs -l /dev/mapper/example 2>/dev/null | head
systemctl status local-fs.target

• Do not substitute a device into filesystem-changing commands until identity and ownership are independently confirmed.
• Compare df allocation with bounded du -x; deleted-but-open files and hidden underlying mountpoint data explain many differences.
• df -i checks inode exhaustion, which can block file creation while byte capacity remains.
• Run filesystem-specific repair only under its documented mount-state and backup requirements.

Evidence and acceptance criteria

Worked scenario: five gigabytes free but file creation fails

A filesystem dashboard shows five gigabytes available, yet an application cannot create queue files. The operator checks byte use, inode use, quota, read-only state, mount options and application identity. Millions of tiny abandoned files have exhausted inodes, while bytes remain available.

The team stops the producer that leaks files, preserves a representative sample, removes only records past the approved retention boundary in controlled batches, and monitors inode pressure. Increasing disk size alone would not necessarily add enough usable inodes or correct the leak.

Practical how-to cases

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
sudo parted /dev/vdb --script mklabel gpt mkpart data xfs 1MiB 100%
sudo mkfs.xfs /dev/vdb1
sudo mkdir -p /srv/data
sudo blkid /dev/vdb1
sudo mount UUID=REPLACE_UUID /srv/data
findmnt /srv/data

sudo cp -a /etc/fstab /etc/fstab.before-data
printf 'UUID=REPLACE_UUID /srv/data xfs defaults 0 0\n' | sudo tee -a /etc/fstab
sudo systemctl daemon-reload
sudo findmnt --verify
sudo umount /srv/data
sudo mount /srv/data
findmnt /srv/data

df -hT /var
df -ih /var
du -x -h --max-depth=1 /var | sort -h
sudo lsof +L1
findmnt -no OPTIONS /var
sudo xfs_quota -x -c 'report -h' /var 2>/dev/null || true

findmnt -T /srv/data
lsblk -f /dev/vdb1
sudo umount /srv/data
sudo xfs_repair -n /dev/vdb1
# ext4 lab volume only: sudo e2fsck -fn /dev/vdc1

sudo mkfs.vfat -n EXCHANGE /dev/vdd1
sudo mkdir -p /mnt/exchange
sudo mount -o uid=1000,gid=1000,umask=0027 LABEL=EXCHANGE /mnt/exchange
findmnt /mnt/exchange
lsblk -f /dev/vdd1

Independent practice tasks

1. Create an ext4 lab filesystem and compare its inspection tools with XFS.
2. Configure x-systemd.automount and prove on-demand behavior.
3. Set an XFS project quota on a lab tree.
4. Recover from a deliberately invalid fstab entry using console access.

For this lesson on RHEL Filesystems and Mount Operations, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: mkfs, partitioning and signature wiping permanently overwrite filesystem metadata. Resolve the exact target and backup before execution.
• Unsafe: running repair on a mounted filesystem when the tool requires offline state can increase corruption. Follow the filesystem-specific procedure.
• Unsafe: recursive deletion based only on a broad path or age can destroy active data and evidence. Inventory and bound exact records.

Rewritten knowledge checks

Guided lab and acceptance test

1. Attach a new disposable virtual disk and record model, serial/path, size, signatures and holders.
2. Create one GPT partition and an XFS filesystem only after confirming the lab target.
3. Mount it by UUID under a dedicated path and validate fstab.
4. Create files, compare byte and inode use and inspect the filesystem with xfs_info.
5. Open a file, unlink its name and use lsof +L1 to explain retained space.
6. Close the descriptor, unmount/remount and reboot to prove persistence, then destroy only the disposable VM disk.

Primary references

• RHEL 10 managing storage devices
• RHEL 10 documentation
• RHEL 9 documentation