What Does df Mean?

Imagine you have several storage bins in your house for different things: one for books, one for holiday decorations, and one for spare tools. Each bin has a limited capacity. To know how full each bin is, you need a way to measure them all at once. In the world of computers, especially servers and personal computers running Linux, the 'df' command is exactly that measuring tape.

When you type 'df' in a terminal, the computer looks at all the partitions (like the different bins) and reports how much total space they have, how much is currently used by files, and how much remains free. It also shows the mount point, which is the location in the file system where you can access that storage. For example, your main hard drive might be mounted at the root (/), while a USB drive might be mounted at /mnt/usb.

Just as you wouldn’t want your decoration bin to overflow and be unable to store new items for next year, a system administrator doesn’t want a critical file system to fill up. If a file system runs out of space, programs can crash, databases can stop working, and users may not be able to save their work. The df command provides a simple, quick way to monitor this vital health metric of any computing system.

The output of df uses units like kilobytes (KB), megabytes (MB), or gigabytes (GB). By default, it shows sizes in 1K blocks, but you can use options like -h (human-readable) to see sizes in a format you might see on your phone's storage settings, like 50G for 50 gigabytes. This makes it easy for anyone, even beginners, to get a clear picture of disk usage at a glance.

The df command, short for 'disk free', is a standard Unix utility that reports the amount of available disk space on file systems. Its origins date back to early Unix systems and it is now a core component of POSIX, making it available on all Linux distributions, macOS, and other Unix-like operating systems. The command reads information from the file system-specific superblocks and inodes. For each mounted file system, df queries the kernel’s virtual file system (VFS) layer, which abstracts the details of the underlying hardware and file system type (such as ext4, XFS, Btrfs, or NTFS). The kernel maintains per-file-system statistics that include total block count, used block count, available block count, and inode usage. Available space typically reflects the amount of space accessible to unprivileged users, which may be less than the total free space because a reserve of blocks (usually 5%) is set aside for the root user to ensure system processes can still write critical logs even when a disk is nearly full.

The standard df output presents several columns: Filesystem (the device or remote share), 1K-blocks (total capacity in 1-kilobyte units), Used (space occupied), Available (space left for regular users), Use% (percentage used), and Mounted on (the directory path where the file system is accessible). The -h flag reformats these values into human-readable units like 'G' (gigabytes) or 'M' (megabytes), which is the most common way administrators use the command day-to-day. Another critical variant is df -i, which displays inode usage rather than block usage. Inodes are data structures that store metadata about files (permissions, timestamps, pointers to data blocks). If you run out of inodes, you cannot create new files even if there is free space, because the file system has run out of slots to store file metadata.

Under the hood, df works by calling the statfs() or statvfs() system call. The kernel retrieves the statistics from the file system driver and populates a structure with the requested data. This makes df a very lightweight operation because it does not need to traverse directory trees or open files; it simply reads pre-cached metadata from memory. This design means df is safe to run frequently and on large file systems without a significant performance penalty. In network file systems like NFS, the command may involve a lightweight remote procedure call (RPC) to the server, but the overhead is still minimal. The utility supports many other options: -T to show the file system type, --exclude-type to ignore certain file systems (like tmpfs or loopback devices), and --sync to force a sync of cached writes before reading disk usage data (useful for obtaining a more accurate real-time snapshot).

For IT professionals, understanding df is not just about running a command but interpreting its output correctly in different contexts. For example, a file system may show 0% available yet still have free space if it is a read-only file system, or it may show a very high Used percentage on a dynamically growing storage like ZFS or Btrfs that uses copy-on-write. On cloud instances, virtual disks might be thin-provisioned, meaning the total reported space does not reflect the actual physical allocation. Docker container environments often use overlay2 file systems that report the capacity of the underlying host filesystem. Knowing these nuances is critical for accurate capacity planning and avoiding false alarms.

Real-world implementations often involve scripting df into monitoring tools like Nagios, Zabbix, or Prometheus. A typical alert threshold triggers when Use% exceeds 80% or 90%. Administrators also use df in combination with other commands like du (disk usage) to identify which directories are consuming space, or with find and sort to locate unusually large files. In exam contexts, you may be asked to construct commands such as `df -h /var/log` to check a specific partition, or `df -i` to troubleshoot a 'No space left on device' error even though df -h reports free space. Mastery of df and its options is a foundational skill for Linux system administration, cloud engineering, and DevOps roles.

In any IT environment, storage is a finite and critical resource. Running out of disk space can cause system crashes, failed backups, stalled databases, and frustrated users. The df command gives a real-time, immediate snapshot of how fast this critical resource is being consumed. For system administrators, operations teams, and DevOps engineers, df is often the first command typed when something goes wrong with writes or performance.

Imagine a production web server where the application logs have been writing silently for days. Without checking df, you would not know that the root file system is at 99% capacity. That tiny remaining space could be reserved for the root user, meaning regular services (like your web server) cannot write new log entries or even update temporary files. The result is an application crash that could take down a customer-facing website. By running df regularly, you can set up proactive alerts (monitoring scripts) that email the team when usage crosses a threshold, allowing you to clean up logs or expand storage before any service interruption occurs.

Beyond immediate crisis management, df supports capacity planning. By tracking historical df output, organizations can model disk usage growth rates and decide when to purchase additional storage or implement cleanup policies. In cloud environments, where storage costs money per GB, running df helps ensure you are not wasting budget on over-provisioned volumes. In Docker container environments, the overlay2 file system can easily fill the host's /var/lib/docker mount point with images and layers; regular df checks can prevent a container from failing to start. Df is a small tool that provides enormous value for maintaining system stability, planning capacity, and troubleshooting disk-related failures. It is a non-negotiable part of every IT professional’s toolkit, from helpdesk support to senior infrastructure architects.

Exam questions typically present a scenario followed by a snippet of df output or ask you to select the correct command to solve a disk-related problem. A common pattern is: 'A systems administrator receives an alert that the /var partition is 95% full. Which command would the administrator use to verify this information?' The correct answer is df -h /var, but distractors might include du -sh /var (which shows the size of the directory contents, not the free space of the partition) or fdisk -l (which lists partition tables, not usage).

Another frequent question type: 'A user reports a 'No space left on device' error when trying to create a file, but df -h shows 10GB free. What is the most likely cause?' This tricky question tests knowledge of inodes. The correct answer is that the file system has run out of inodes, which can be confirmed with df -i. Learners who only know df -h will be misled by the free space. The exam wants you to diagnose the real issue.

Performance-based questions (PBQs) in Linux+ and RHCSA can be more complex. You might log into a virtual terminal and run df to check space on a mounted NFS share, then use another command like mount or lsblk to verify the share is still mounted. Or you might receive a df output with multiple lines and be asked to identify which file system corresponds to the root partition, which one is a tempfs, and which is a remote NFS mount. This tests your ability to parse the 'Filesystem' column and understand device names (/dev/sda1), tmpfs, and host:path formats.

Questions also combine df with planning. For example: 'A new log rotation policy needs to retain logs for 30 days on the /var/log partition. Current usage is 80% of a 100GB partition. Assuming 1GB of log growth per day, will the partition have enough space for the new policy?' This involves interpreting df output and doing simple arithmetic. In all cases, the exam expects you to not only know the command but to use it analytically in real-world scenarios. The most common trick is overlooking the -h flag: the default output uses 1K blocks, which can make a 50GB partition look like 50 million blocks, confusing an unprepared candidate. Always use -h in multiple-choice answers when the output is shown in human-readable form.

The df command is a fundamental tool for any systems administrator, DevOps engineer, or IT support professional. In practice, you rarely run df in isolation; it is part of a diagnostic workflow. Suppose a monitoring system alerts you that a production database server's /var/lib/mysql partition is at 85% capacity. Your first action is to SSH into the server and run df -h to confirm the alert. You see that the partition is indeed 85% used. Now you need to determine the growth rate. You run df -h again after 5 minutes, and the percentage has not changed, but you know that logs are being written. You then run df -i to check inodes, because a table corruption could have created millions of small temporary files. The inode usage is at 2%, so that is not the issue.

Next, you identify the largest contributors to disk usage within that partition. You use the du command: du -sh /var/lib/mysql/* | sort -rh | head -10. This shows the ten largest databases or files. You find a database that is 200GB but has not been accessed in six months. After confirming with the application team, you archive and remove it, recovering space. You run df -h again and see usage has dropped to 60%. To prevent future issues, you set up a cron job that runs df -h nightly and emails the results to you, and you also add disk usage thresholds to your monitoring platform.

Another real-world nuance: you may need to run df on a server that uses logical volume management (LVM). In such cases, df shows the logical volume device (like /dev/mapper/vg_root-lv_root). Before you can extend that volume, you need to check the underlying volume group and physical volumes using commands like vgdisplay and pvdisplay. Running df first gives you the current usage, which tells you the minimum size the volume needs to be extended. If you extend a logical volume without understanding the df usage, you might allocate too much or too little space. This interdependence between df and LVM tools is a hallmark of professional system administration.

What can go wrong? If you run df while a file system is under heavy write load, the numbers may be slightly stale because the kernel caches metadata. This is usually fine for capacity monitoring, but for precision, you can use the --sync option to force a file system sync before reading. Another common issue is df hanging on an NFS mount that has lost connectivity. In such cases, you can use the --timeout option or run df with the -l flag to list only local file systems. For scripting, always use df -hP (the -P flag enables POSIX output format) to avoid line-wrapping on long device names, which can break scripts that parse the output. Mastering df means knowing not just the command and options, but also the context of the surrounding tools (du, LVM, mount, lsblk) and the operational pitfalls to avoid.