duFind out which files and directories use the space
du walks a directory tree and adds up the disk space its files use. Where df tells you a filesystem is full, du tells you what filled it: sorted by size, it leads you straight to the culprit directory.
du [OPTION]... [FILE]...Before copying your app to another server, you want to know its size and what makes up most of it.
sudoRun as root so du can read every directory; otherwise unreadable ones are skipped with errors.
du traverses the tree (the fts library: openat, getdents64, then fstatat on every entry). For each file it adds st_blocks x 512 bytes: the space actually allocated on disk, not the file's length. So a 3-byte file counts as 4.0K (one block), and a sparse 20G VM image with 1.3G written counts as 1.3G; --apparent-size uses the length (st_size) instead. du remembers device and inode numbers so hard-linked files are counted once per run. -x compares st_dev and stops at mount points. Since it only sees files that have a name, du can't count deleted files held open by a process, or files hidden underneath a mount point. On millions of files it is slow and generates a lot of metadata I/O, so on a busy server run it with ionice -c3.
-sSummarize: one total per argument instead of every subdirectory-hHuman-readable sizes; pair with sort -h-d N / --max-depth=NOnly print totals down to depth N-xStay on one filesystem (skip other mounts)-aInclude files, not just directories-cPrint a grand total at the end--apparent-sizeUse file length instead of allocated blocks (sparse files look big)--exclude=PATTERNSkip files matching a glob, e.g. --exclude='*.iso'-t SIZEOnly show entries at least this big: -t 1G--inodesCount files (inodes) instead of space: find where the small files are--timeShow the newest modification time in each directorydu -sh /* to find what's filling the root diskWithout -x du also descends into /proc, /sys, /data and other mounts, which is slow and adds space that isn't on /.
sudo du -xh -d1 / | sort -rh | headsort -n on du -h outputNumeric sort ignores the unit, so 900K sorts above 2G.
du -h ... | sort -h (or -rh for biggest first)Expecting du / to match df after deleting a big fileIf a process still has the file open, df still counts it but du can't see it.
sudo lsof -nP +L1, then restart or truncate via /proc/PID/fd/NUsing du on a busy production database volume in the middle of the daydu stats every file and can cause heavy metadata I/O on millions of files.
ionice -c3 nice du -xh -d1 /data | sort -rhTry these on a Linux machine of your own. Each task has a hint and a solution.
Show the total size of ~/logs in human-readable form.
List the size of every entry in ~/app, sorted with the largest last.
Find the 5 biggest directories under /var, without leaving the root filesystem.
Which subdirectory of ~/data contains the most files?
duFind out which files and directories use the space
du walks a directory tree and adds up the disk space its files use. Where df tells you a filesystem is full, du tells you what filled it: sorted by size, it leads you straight to the culprit directory.
du [OPTION]... [FILE]...Before copying your app to another server, you want to know its size and what makes up most of it.
sudoRun as root so du can read every directory; otherwise unreadable ones are skipped with errors.
du traverses the tree (the fts library: openat, getdents64, then fstatat on every entry). For each file it adds st_blocks x 512 bytes: the space actually allocated on disk, not the file's length. So a 3-byte file counts as 4.0K (one block), and a sparse 20G VM image with 1.3G written counts as 1.3G; --apparent-size uses the length (st_size) instead. du remembers device and inode numbers so hard-linked files are counted once per run. -x compares st_dev and stops at mount points. Since it only sees files that have a name, du can't count deleted files held open by a process, or files hidden underneath a mount point. On millions of files it is slow and generates a lot of metadata I/O, so on a busy server run it with ionice -c3.
-sSummarize: one total per argument instead of every subdirectory-hHuman-readable sizes; pair with sort -h-d N / --max-depth=NOnly print totals down to depth N-xStay on one filesystem (skip other mounts)-aInclude files, not just directories-cPrint a grand total at the end--apparent-sizeUse file length instead of allocated blocks (sparse files look big)--exclude=PATTERNSkip files matching a glob, e.g. --exclude='*.iso'-t SIZEOnly show entries at least this big: -t 1G--inodesCount files (inodes) instead of space: find where the small files are--timeShow the newest modification time in each directorydu -sh /* to find what's filling the root diskWithout -x du also descends into /proc, /sys, /data and other mounts, which is slow and adds space that isn't on /.
sudo du -xh -d1 / | sort -rh | headsort -n on du -h outputNumeric sort ignores the unit, so 900K sorts above 2G.
du -h ... | sort -h (or -rh for biggest first)Expecting du / to match df after deleting a big fileIf a process still has the file open, df still counts it but du can't see it.
sudo lsof -nP +L1, then restart or truncate via /proc/PID/fd/NUsing du on a busy production database volume in the middle of the daydu stats every file and can cause heavy metadata I/O on millions of files.
ionice -c3 nice du -xh -d1 /data | sort -rhTry these on a Linux machine of your own. Each task has a hint and a solution.
Show the total size of ~/logs in human-readable form.
List the size of every entry in ~/app, sorted with the largest last.
Find the 5 biggest directories under /var, without leaving the root filesystem.
Which subdirectory of ~/data contains the most files?