Filesystem capacity has at least two limits: data blocks and metadata objects such as inodes. df reports allocation from the filesystem's perspective, while du walks reachable pathnames and sums usage attributed to them. The values answer different questions and need not match.
The Filesystem · Lesson 9
Disk Usage
Learn how `df` and `du` measure different views of filesystem block and inode consumption.
Filesystem Capacity with `df`
Show mounted filesystem type and human-readable block figures with:
$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext4 6.2G 2.3G 3.6G 40% /
Size, Used, and Avail come from filesystem accounting. Available space can be less than total minus used because of reserved blocks, metadata, allocation policy, quotas, or rounding. Run df on a path to report the filesystem containing that path:
$ df -hT /var/log
What does df primarily report?
Inode Capacity
Filesystems that allocate inode-like objects can exhaust them even while blocks remain:
$ df -i /var
Large numbers of tiny files can consume available inodes. Deleting one large file frees many blocks but generally only one inode; deleting many unnecessary small files can relieve inode pressure. Some filesystems allocate metadata dynamically and report these concepts differently.
What can happen when a filesystem has free blocks but no free inodes?
Path Usage with `du`
Summarize allocated space reachable below one directory:
$ du -sh /var/log
Compare immediate children while staying on one filesystem:
$ sudo du -xhd1 /var | sort -h
GNU options shown here mean human-readable output, maximum depth one, and one filesystem. Permissions can hide subtrees and produce an incomplete total. du can also count hard-linked files only once by default, distinguish apparent size from allocated blocks, and treat sparse files differently depending on options.
Which command summarizes allocated usage under /var/log?
Why `df` and `du` Differ
Common causes include:
- a process keeps a deleted file open, so its blocks remain allocated but no pathname exists for
du - filesystem metadata, reserved space, journals, reflinks, snapshots, or compression affect accounting
- another filesystem is mounted within the walked tree
- permissions prevent
dufrom reading some directories - sparse files have different apparent and allocated sizes
For deleted-but-open files, inspect authorized processes with a tool such as lsof +L1; restart or signal the responsible service through its normal procedure rather than truncating unknown descriptors.
Why can df show space in use that pathname-based du cannot find?
Investigating Without Making the Incident Worse
Start at the full filesystem reported by df, identify its mount target with findmnt, then narrow du searches on that same filesystem. Account for snapshots, container layers, logs, package caches, and application retention policy. Do not delete files solely because they are large; determine ownership, backup, compliance, and service behavior first.
What is the safest response to finding a large file?
Lesson complete
You finished Disk Usage
You can now reconcile filesystem and pathname-based space reports.
Use
dffor mounted filesystem block capacity.Use
df -ifor inode pressure where supported.Use scoped
duwalks to attribute reachable path usage.Investigate deleted-open files and filesystem-specific accounting differences.
Apply ownership and retention policy before deleting data.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account