Distinguish full filesystems from full disks with df

Detailed practical guide

Prepare your workspace and inputs

Get the exact path from the failed write, such as /var/lib/example. Replace the sample path only after confirming it belongs to the affected service. Use a permitted test host or read-only production session.

Platform context: Linux with GNU coreutils and findutils; read-only diagnostics. Commands do not delete or truncate files.

Scenario to reproduce or investigate

An application reports no space left on device. Looking at a different mount, counting only bytes or deleting unrelated logs can miss the cause and destroy evidence.

1. Resolve the path to its actual filesystem

   Ask df about the application path rather than relying on the first line of a system-wide report. The path must exist. Record the mounted filesystem, capacity and free blocks before searching directories.

   Command, configuration or input

   df -h /var/lib/example
   df -i /var/lib/example

   Expected result · ผลที่ควรเห็น

   Both commands identify the same target mount. df -h shows block usage; df -i shows inode usage. Either resource can be exhausted independently.

   If it fails · เมื่อไม่ผ่าน

   If the path does not exist, find the documented existing parent and check whether a missing mount is involved. Do not create a replacement directory to make df succeed.

2. Bound the search to the affected filesystem

   Read the first directory level within that mount. The -x option prevents crossing into another filesystem, while --max-depth=1 bounds the report. Directory traversal can still consume I/O on a large production tree, so choose an approved interval.

   Command, configuration or input

   du -x -h --max-depth=1 /var/lib/example

   Expected result · ผลที่ควรเห็น

   The report identifies which immediate subtree accounts for the space visible to this identity. A permission error means the total is incomplete.

   If it fails · เมื่อไม่ผ่าน

   If df reports far more usage than du, investigate open deleted files, snapshots, reserved space and inaccessible directories through the host-approved tools. Do not assume the discrepancy is corruption.

3. Choose a retention or capacity correction with an owner

   For block exhaustion, identify which data owner can expire, archive or expand the specific workload data. For inode exhaustion, examine high file counts in the identified subtree and its retention behavior. Apply any removal only through the application-supported process. Repeat both df checks and the original write operation after the correction.

   Command, configuration or input

   Before/after record: mount | free blocks | free inodes | workload write result | retention owner

   Expected result · ผลที่ควรเห็น

   The corrected workload can perform its intended write and the constrained resource has measurable headroom; unrelated mounts remain unchanged.

   If it fails · เมื่อไม่ผ่าน

   If free space recovers but the write still fails, check quota, read-only mount state and the application identity. A successful root test is not the same as a successful application write.

Recovery and cleanup

The diagnostic commands need no rollback. For a later retention change, retain the previous policy and a recoverable copy of data selected for archive; deletion is not automatically reversible.

Apply to actual work and known limits

Run the same path-scoped comparison during an incident and add the limiting resource to monitoring. Use the application retention policy instead of copying a generic delete command from a disk-space article.

Authored against the cited documentation. Execution on the stated vendor product or physical equipment remains to be verified.