When dealing with Ext4 filesystems, it's not uncommon to encounter discrepancies between df (disk free) and du (disk usage) reports. Let's examine a real-world case where:

df -h /dev/md1
Filesystem      Size  Used Avail Use% Mounted on
/dev/md1        20G   3.3G   15G  18% /

du -shx /
948M    /

Before considering reformatting, these diagnostic methods can reveal the root cause:

# Check for reserved blocks
tune2fs -l /dev/md1 | grep -i "block count"

# Examine journal size
dumpe2fs -h /dev/md1 | grep -i journal

# Find hidden deleted files
lsof +L1 | grep '/dev/md1'

# Check for snapshots (if LVM is used)
lvdisplay | grep -i snapshot

Based on similar cases I've troubleshooted, these are the most likely causes:

• Reserved blocks: Default is 5% for root, which would account for ~1GB in this 20GB partition
• Journaling overhead: Ext4 maintains transaction logs (typically 128MB)
• Orphaned inodes: Files deleted while still open by processes
• Filesystem features: Extents, inline data, or other metadata structures

Try these commands to potentially reclaim space:

# Method 1: Clear systemd journals (if applicable)
journalctl --vacuum-size=100M

# Method 2: Force filesystem check on reboot
touch /forcefsck
shutdown -r now

# Method 3: Adjust reserved blocks percentage
tune2fs -m 1 /dev/md1  # Sets reserved blocks to 1%

For deeper investigation, run an offline check:

umount /dev/md1
fsck -nf /dev/md1  # Dry run first!
# If errors found:
fsck -y /dev/md1

Before reformatting, ensure you've:

1. Backed up all critical data
2. Tried debugfs to examine filesystem internals
3. Verified no RAID sync issues exist

# Example debugfs session
debugfs /dev/md1
debugfs: stats
debugfs: list_deleted_inodes
debugfs: quit

When working with Linux systems, particularly those using Ext4 filesystems, administrators occasionally encounter puzzling discrepancies between the disk space reported by df and du. In this specific case with CentOS 6, we observe:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/md1         20G  3.3G   15G  18% /

$ du -sm -x /
948     /

Several factors could explain why df reports significantly more used space than du:

• Deleted files still held by processes: Files deleted but kept open by running processes
• Journaling overhead: Ext4 journal consuming reserved space
• Reserved blocks: Default 5% reserved for root
• Filesystem metadata: Inodes, bitmaps, and other structures
• Hidden system files: Special files not counted by du

Before considering reformatting, let's thoroughly investigate:

# Check for deleted but still open files
$ sudo lsof +L1 | grep deleted

# Verify reserved blocks percentage
$ sudo tune2fs -l /dev/md1 | grep -i "block count"

# Check filesystem errors
$ sudo fsck -n /dev/md1

# Examine journal size
$ sudo dumpe2fs /dev/md1 | grep -i journal

For deeper analysis, consider these approaches:

# Show all mounted filesystems with space usage
$ sudo df -h --total

# Find largest directories (excluding mounted filesystems)
$ sudo du -xSh / | sort -rh | head -20

# Check for sparse files
$ find / -type f -printf '%S\t%p\n' | sort -n

Based on the investigation, here are potential solutions:

# If deleted files are the issue
$ sudo service problematic-service restart

# To adjust reserved blocks (example: reduce to 1%)
$ sudo tune2fs -m 1 /dev/md1

# If journal is too large (example: reduce to 32MB)
$ sudo tune2fs -J size=32 /dev/md1

To avoid similar issues in the future:

• Implement regular storage monitoring
• Set up alerts for unusual space consumption
• Consider using LVM for easier management
• Keep system services properly configured to clean up temporary files