How to investigate low disk space in Linux

Low disk space in Linux can break writes long before the largest visible directory is obvious. Package updates, databases, queues, and log-heavy services may fail when the filesystem behind the problem path runs out of free blocks or free inodes.

Start by checking the filesystem that contains the path reporting the problem. df shows block pressure, df -i shows inode pressure, and findmnt identifies the mount point and source device so later scans stay on the affected filesystem instead of crossing into unrelated mounts.

The examples use /var because logs, package caches, and application state often collect there. Replace /var with the path that is actually failing, keep du -x and find -xdev on the same filesystem, and treat deleted-but-open files or snapshot-backed storage as separate causes when df and du do not agree.

1. Check block usage for the path reporting low space.

   $ df -hPT /var
   Filesystem     Type  Size  Used Avail Use% Mounted on
   /dev/vda2      ext4   59G   56G  1.2G  98% /

   The Use% column shows block pressure for the filesystem that contains /var, not the size of /var itself.

2. Check inode usage for the same path.

   $ df -iP /var
   Filesystem      Inodes   IUsed   IFree IUse% Mounted on
   /dev/vda2      3907584  614508 3293076   16% /

   IUse% reaching 100 percent can stop new file creation even when the block Avail column still shows free space.

3. Identify the mount point and source device behind the path.

   $ findmnt -T /var -o TARGET,SOURCE,FSTYPE
   TARGET SOURCE    FSTYPE
   /      /dev/vda2 ext4

   Use the TARGET value when narrowing filesystem-wide checks such as deleted-open files.
   Related: How to check mount point usage in Linux

4. Summarize top-level directory usage on the affected filesystem.

   $ sudo du -xhd1 /var
   25M	/var/log
   4.0K	/var/mail
   4.0K	/var/opt
   4.0K	/var/local
   4.0K	/var/backups
   8.0K	/var/tmp
   65M	/var/cache
   4.0K	/var/spool
   140M	/var/lib
   228M	/var

   -x keeps du from counting nested filesystems under the target path.
   Related: How to find the largest directories in Linux

5. Inspect the largest subtree from the previous check.

   $ sudo du -xhd1 /var/lib
   38M	/var/lib/apt
   12K	/var/lib/pebble
   364K	/var/lib/systemd
   28K	/var/lib/pam
   5.0M	/var/lib/dpkg
   4.0K	/var/lib/misc
   4.0K	/var/lib/dbus
   97M	/var/lib/example-app
   4.0K	/var/lib/private
   140M	/var/lib

   Move down one level at a time until the output points to an application, cache, log, backup, or data directory that can be reviewed safely.

6. Find regular files above a chosen size threshold on the same filesystem.

   $ sudo find /var -xdev -type f -size +20M -ls
   2755930  24576 -rw-r--r--   1 root root  25165824 Jun 13 10:49 /var/log/example-app/app.log
   2755929  65536 -rw-r--r--   1 root root  67108864 Jun 13 10:49 /var/cache/example-app/objects.cache
   2755769  31824 -rw-r--r--   1 root root  32585894 Apr 23 17:07 /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_resolute_universe_binary-amd64_Packages.lz4
   2755928  98304 -rw-r--r--   1 root root 100663296 Jun 13 10:49 /var/lib/example-app/archive.db

   Raise or lower -size +20M for the host. A smaller threshold finds more files, while a larger threshold keeps the output focused.
   Related: How to find the largest files in Linux

7. Check whether deleted files are still consuming blocks.

   $ sudo lsof +aL1 /
   COMMAND  PID USER FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
   python3 2146 app  3w   REG  253,2 33554432     0 2762737 /var/log/example-app/held.log (deleted)

   Space from a (deleted) file is released only after the owning process closes the descriptor, usually through a service reload, restart, or clean process exit.
   Related: How to check deleted files still open in Linux

8. Check how much space the systemd journal is using.

   $ sudo journalctl --disk-usage
   Archived and active journals take up 0B in the file system.

   A small or 0B journal means persistent journal files are not the main consumer on this host. A large journal total should be compared with other log directories before cleanup.
   Related: How to check systemd journal size in Linux

9. Compare plain-text log directory usage under /var/log.

   $ sudo du -xhd1 /var/log
   52K	/var/log/apt
   4.0K	/var/log/journal
   25M	/var/log/example-app
   4.0K	/var/log/private
   25M	/var/log

   Plain-text logs can dominate even when the systemd journal is small.
   Related: How to check log directory sizes in Linux

10. Compare the visible path total with the filesystem total from df.

    $ sudo du -shx /var
    228M	/var

    If df shows far more used space than du can see under the problem path, keep investigating deleted-open files, snapshots, reserved blocks, copy-on-write metadata, or usage elsewhere on the same filesystem before deleting random files.
    Related: How to free disk space on Linux