df (short for disk free) is the Linux command that reports the total size, used space and available space of every mounted filesystem, together with the mount point where each one is attached. In Linux monitoring it is the first tool administrators reach for when a service fails with “No space left on device”, and it is a standard data source for alerting on filesystem capacity.
The df command reads its figures from the kernel through the statfs system call, so it answers instantly regardless of how many files a volume holds. It describes filesystems as a whole; to find out which directories consume the space, administrators turn to its neighbor du.
How df obtains its numbers
For each mount listed in /proc/self/mounts, df calls statfs() or statvfs(), which returns the block size, total blocks, free blocks and blocks available to unprivileged users, plus the matching inode counts. df multiplies these by the block size and prints the result. Because it never walks the directory tree, df is fast even on multi-terabyte volumes.
The difference between free and available blocks is essential. On ext4, about 5 percent of blocks are reserved for root by default, so ordinary users may hit a full disk while root can still write. df shows the reserved part neither as used nor as available, which is why Used plus Avail is often smaller than Size.
The default output columns and their meaning are listed below.
| Column | Meaning | Notes |
|---|---|---|
| Filesystem | Source device or pseudo filesystem | For example /dev/nvme0n1p2 or tmpfs |
| Size | Total capacity | Excludes filesystem metadata overhead |
| Used | Space consumed by data and metadata | Counts deleted files still held open |
| Avail | Space writable by normal users | Excludes root-reserved blocks |
| Use% | Used divided by Used plus Avail | Rounded up, so 99.1 shows as 100 |
| Mounted on | Mount point in the directory tree | Where the filesystem is visible |
Essential df options
GNU coreutils df, the version shipped by most Linux distributions, offers options for human-readable sizes, inode reports, type filtering and custom columns. Busybox df on embedded systems supports a smaller subset.
| Option | Effect | Typical use |
|---|---|---|
| -h | Sizes in powers of 1024 (K, M, G) | Quick interactive check |
| -H | Sizes in powers of 1000 | Matching vendor-reported disk sizes |
| -i | Inode totals, used, free and IUse% | Diagnosing inode exhaustion |
| -T | Adds a filesystem type column | Distinguishing ext4, xfs, tmpfs, nfs |
| -x tmpfs -x devtmpfs | Excludes listed types | Hiding memory-backed mounts |
| -l | Local filesystems only | Avoiding slow or hung network mounts |
| –output= | Selects specific fields | Machine-readable output for scripts |
| -P | POSIX format on one line per mount | Stable parsing in shell scripts |
For scripts, df --output=target,pcent -x tmpfs or df -P produces stable, parseable output. Running df against a path, as in df -h /var/log, reports only the filesystem that contains that path, which is the quickest way to learn which volume a directory lives on.
df compared with du and other monitoring tools
df and du answer different questions and often disagree. df asks the filesystem how many blocks are allocated; du walks directories and sums the sizes of files it can reach. Neighboring Terms in Linux monitoring cover the remaining angles of storage health.
| Tool | Question it answers | Data source |
|---|---|---|
| df | How full is each filesystem | statfs per mount |
| du | Which directories use the space | Recursive directory walk |
| lsof | Which processes hold deleted files open | /proc file descriptor tables |
| iostat | How busy is each block device | /proc/diskstats |
| iotop | Which processes generate disk I/O | Per-task I/O accounting |
| lsblk | How disks and partitions are laid out | sysfs block device tree |
When df shows a full disk but du finds far less data, the usual causes are files deleted while a process still holds them open, data hidden under a mount point, or space consumed by filesystem snapshots.
Interpreting df on modern filesystems
Copy-on-write and pooled filesystems complicate the simple model. On Btrfs, df reports a rough estimate because data and metadata profiles such as RAID1 consume raw space at different rates; btrfs filesystem usage gives the accurate picture. On ZFS, all datasets in a pool share free space, so each dataset shows the same Avail value, and zfs list is the authoritative tool.
Pseudo filesystems such as tmpfs, devtmpfs and overlay also appear in df. A tmpfs size is a limit on memory use, not disk space, and an overlay mount in a container reports the capacity of the host filesystem underneath it.
Pitfalls and alerting practice
Most disk-related outages come from a small set of recurring situations. The table maps symptoms to their causes and the corrective action.
| Symptom | Likely cause | Fix |
|---|---|---|
| Writes fail, df shows free space | Inode exhaustion | Check df -i, remove many small files |
| df and du disagree by gigabytes | Deleted files still open | lsof +L1, then restart the process |
| df hangs | Unresponsive NFS or CIFS mount | Use df -l or fix the network mount |
| Use% at 100, root can still write | Reserved blocks in use | Free space or adjust with tune2fs -m |
| Sudden jump in Used | Runaway logs or core dumps | Rotate logs, limit journald size |
In monitoring systems, alert on both space and inode usage, typically warning at 80 to 85 percent and paging at 90 to 95 percent, and add a rate-of-change alert that predicts when a volume will fill. A volume that grows from 60 to 85 percent in an hour deserves more urgency than one that has sat at 88 percent for months.
In plain words
Think of each disk on a computer as a storage room. df is a quick inventory sheet that lists every room, how big it is, how much is already filled and how much shelf space is left. It does not open boxes to see what is inside; it simply reads the counter on the door.
That makes it the fastest way to answer the question “is anything about to run out of room”. When the answer is yes, a different tool is used to find out which boxes are taking up the space.
A real-world example
An online shop’s database server starts rejecting orders at night with write errors. The on-call administrator runs df -h and sees /var at 100 percent, although du reports only 31 GB of data on a 50 GB volume. Running lsof +L1 reveals a log file of about 19 GB that logrotate deleted while the application still held it open.
Restarting the logging service releases the file and df drops to 62 percent within seconds. The team then adds a copytruncate setting to the rotation rule and a monitoring alert at 85 percent usage, and the same failure does not return during the following peak season.