Disk nearly full? These commands find the largest files and directories in seconds, so you can decide what to delete, compress or move.

The biggest files on the system

sudo find / -xdev -type f -size +100M -exec ls -lh {} + 2>/dev/null | sort -k5 -h | tail -20
  • -xdev — stay on the root filesystem (skip /proc, other disks, network mounts).
  • -size +100M — larger than 100 MB; adjust as needed (+1G).
  • ls -lh + sort -k5 -h — show sizes and sort by them.

A faster variant using find’s own formatting:

sudo find / -xdev -type f -size +50M -printf '%s\t%p\n' 2>/dev/null | sort -n | tail -20 | awk -F'\t' '{ printf "%8.1f MB  %s\n", $1/1048576, $2 }'

The biggest directories

sudo du -xh -d 1 / 2>/dev/null | sort -h | tail -15

Then descend into the biggest one and repeat:

sudo du -xh -d 1 /var 2>/dev/null | sort -h | tail -15

See the du command for more options.

Interactive: ncdu

sudo apt install ncdu        # dnf install ncdu on RHEL family (EPEL)
sudo ncdu -x /

Navigate with arrow keys, sort by size, press d to delete. For most cleanups this is the fastest workflow.

Recently grown files

Something filling the disk right now? Look for large files modified in the last hour or day:

sudo find / -xdev -type f -mmin -60 -size +10M -printf '%TY-%Tm-%Td %TH:%TM  %s  %p\n' 2>/dev/null | sort -k3 -n | tail
sudo find /var -xdev -type f -mtime -1 -size +100M -ls 2>/dev/null

A log growing by gigabytes per hour usually means an application error loop — fix the cause, not just the file.

Deleted files that still use space

If df shows the disk full but du and find don’t find enough files, a process may be holding deleted files open. The space isn’t released until the process closes them:

sudo lsof +L1
sudo lsof -nP +L1 | awk '$7 > 100000000'      # those bigger than ~100 MB

Typical case: you deleted a huge log while the service was still writing to it. Restart (or reload) that service to free the space. Next time, truncate instead of deleting:

sudo truncate -s 0 /var/log/app/huge.log

Usual suspects on servers

sudo du -sh /var/log /var/lib/docker /var/lib/mysql /var/lib/postgresql /var/cache /home /root /tmp 2>/dev/null
journalctl --disk-usage
Location What to do
/var/log/*.log, *.gz Delete old rotated logs; configure logrotate
/var/log/journal sudo journalctl --vacuum-size=500M
/var/lib/docker docker system df, then prune safely
Database binary logs Set expiry (binlog_expire_logs_seconds), purge old ones
/var/cache/apt/archives sudo apt clean
Old kernels sudo apt autoremove --purge
Backups in /root, /home, /var/backups Move off-server, keep a retention policy
core dump files Delete; disable or redirect core dumps
Web app caches and sessions Clear via the app; check for missing cleanup jobs

Find files by type

sudo find / -xdev -type f \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.tar.gz' -o -name '*.zip' \) -size +50M -ls 2>/dev/null
sudo find / -xdev -type f -name 'core*' -size +1M -ls 2>/dev/null
sudo find /var/www -type f -name '*.log' -size +10M -ls

Old database dumps and archive files left behind after migrations are among the most common forgotten space hogs.

Delete carefully

  • Look before you delete: ls -lh, file, head on the path.
  • Never delete files under /var/lib/mysql or /var/lib/postgresql by hand — use the database’s own tools.
  • Prefer moving uncertain files to another disk first.
  • Use find … -delete only after the same command without -delete shows the right list.

Prevent the next full disk

  • Log rotation and journald size limits.
  • Docker log limits (max-size) — see Docker logs.
  • Backup retention with automatic cleanup.
  • An alert at 80–85% usage — see df command for a simple script.

For the full emergency procedure, see disk full troubleshooting. If your data simply needs more room, a Storage VPS offers large SSD capacity.

  • Linux
  • Disk Space
  • Troubleshooting