Learn › Linux Foundations › Reading Files
du - a hands-on Linux lab on a real virtual machine.
Weigh files and folders on disk with du. See why on-disk blocks differ from exact bytes (du -b matches wc -c), read sizes with -h, weigh several files in one command, and learn du -sh for one-line folder totals, right in the practice terminal on the intercept filesystem.
You have been reading files all module: cat to print them, head and tail to skim the ends, wc to count what is inside. Every one of those looks at the content. None of them answers a different, very practical question: how much room is this thing taking up on the disk?
That matters the moment a disk fills up. When there is no space left, the machine stops writing logs, stops saving files, sometimes stops working at all. The first thing you need to know is which files and folders are the heavy ones. The command that weighs them is du, short for disk usage.
You are working in a folder called intercept, sitting in your home directory. Inside it are three subfolders: logs, intel, and binaries. One file in logs is deliberately huge next to the others. Let us weigh it.
The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. du is preinstalled on Linux, so on the real machine at the end of the module you run these for real against the same intercept folder.
Point du at a single file and it prints one number and the file's name. First move into the folder, then weigh the big log:
cd ~/intercept
prompt: student@linuxcamp:~$ answer: cd ~/intercept output: hint: Type cd, a space, then the path to the folder: cd ~/intercept
cd prints nothing when it works. That blank line is success: Linux quietly moved you into intercept. The prompt now ends in ~/intercept.
Now weigh the large log file, logs/bulk.log:
du logs/bulk.log
prompt: student@linuxcamp:~/intercept$ answer: du logs/bulk.log output: 12 logs/bulk.log hint: Type du, a space, then the path to the file: du logs/bulk.log
One number, 12, then the name. By default du reports size in blocks of 1024 bytes each, which is roughly kilobytes. So 12 means this file takes about 12 kilobytes of room on the disk.
Here is the catch that trips everyone up at first: that number is space on the disk, not the exact byte count of the content. Disks hand out space in fixed-size chunks, so a file almost always rounds up to the next chunk. The next step shows you the exact bytes, and why the two numbers differ.
wc -c told you the exact size of a file's content in bytes. du tells you how much room it actually occupies on the disk. Those are two different numbers, and seeing them side by side is the whole idea.
Ask wc -c for the exact byte count of bulk.log first:
wc -c logs/bulk.log
prompt: student@linuxcamp:~/intercept$ answer: wc -c logs/bulk.log output: 10001 logs/bulk.log hint: You met this in the wc lesson: wc -c logs/bulk.log
Now ask du for the same file's size in bytes, using the -b flag. -b stands for bytes, and it makes du report the exact content size instead of rounded blocks:
du -b logs/bulk.log
prompt: student@linuxcamp:~/intercept$ answer: du -b logs/bulk.log output: 10001 logs/bulk.log hint: Add the -b flag between du and the path: du -b logs/bulk.log
du -b prints 10001, exactly matching wc -c. That is the true byte count of the content. But plain du reported 12 blocks, which is about 12288 bytes of disk. The file needs a little over 9K of content, and the disk rounds it up to the next full set of chunks. That rounded-up number is the space you actually cannot use for anything else.
Remember the split: du -b is exact bytes (it equals wc -c), and plain du is rounded disk blocks. When someone asks "how big is this file," the honest answer depends on which one they mean.
Raw block counts are fine for one file, but they get hard to read fast. The -h flag fixes that. -h stands for human-readable, and it prints sizes with units: K for kilobytes, M for megabytes, G for gigabytes.
Weigh the same big log, but readable this time:
du -h logs/bulk.log
prompt: student@linuxcamp:~/intercept$ answer: du -h logs/bulk.log output: 12K logs/bulk.log hint: Add the -h flag between du and the path: du -h logs/bulk.log
12K is the same 12 blocks you saw earlier, now labelled: 12 kilobytes. The number did not change, only its clothing. On a real disk you will see 4.0K, 256M, 1.2G, and being able to compare those at a glance is exactly why almost everyone reaches for -h by default.
du is not limited to one path. Hand it several files in one command and it prints one line per file, each with its own size. Combine that with -b and every line is exact bytes, the same numbers wc -c would give you.
Before you run this, decide: which log file will show the bigger number, messages.log or bulk.log?
du -b logs/messages.log logs/bulk.log
prompt: student@linuxcamp:~/intercept$ answer: du -b logs/messages.log logs/bulk.log output: 208 logs/messages.log 10001 logs/bulk.log hint: Give du -b both paths, separated by a space: du -b logs/messages.log logs/bulk.log
Two lines, one per file, in the order you listed them. messages.log is a slim 208 bytes; bulk.log dwarfs it at 10001. This is how you compare suspects side by side when a disk fills up: name them all in one du command and read the numbers straight down.
Files are only half the job. Point du at a folder and it adds up everything inside, then reports the total. This is where du earns its keep: one number for a whole directory tree.
Two details about that total. First, when a folder has subfolders, plain du prints a line for every subfolder on the way to the total, which can be a lot of scrolling. Adding -s, short for summary, collapses it all into a single line. Second, the total is measured in disk blocks, so every file inside is rounded up to full blocks, and the folder itself carries one small bookkeeping block of its own.
-s pairs with -h so often that du -sh is one command people type from memory. It works on files too, so practice the pair on the file you already know:
du -sh logs/bulk.log
prompt: student@linuxcamp:~/intercept$ answer: du -sh logs/bulk.log output: 12K logs/bulk.log hint: Combine -s and -h into -sh, then the path: du -sh logs/bulk.log
The same 12K as before. On a single file -s changes nothing, because one file is already one line. The payoff comes on folders: du -sh logs answers "how big is the whole logs folder?" in exactly one line, rounding included.
You may notice we did not print a folder total here. That is deliberate. Because every file rounds up to full blocks and the folder adds its own bookkeeping block, the exact figure depends on how each filesystem hands out blocks. On the real machine at the end of the module you run du -sh logs yourself and read the honest number straight off the real disk.
Scaffolding off. No command is shown this time. You have every piece you need.
A colleague asks for the exact byte size of intel/roster.txt, not a rounded disk figure. You know the du flag that reports true bytes instead of blocks. Aim du at that file and ask for bytes.
prompt: student@linuxcamp:~/intercept$ answer: du -b intel/roster.txt output: 86 intel/roster.txt hint: Think back to the step where du matched wc -c exactly. That was the -b flag. Point du -b at intel/roster.txt.
86 bytes, exact to the byte, because -b reports true content size rather than rounded disk blocks. You could confirm it with wc -c intel/roster.txt and get the same 86. You recalled the right flag from memory and pointed it at the right file, which is exactly the move the real machine will ask of you.
Another request, still no command shown. This time the question is about disk space, not bytes. How much room is logs/bulk.log taking on the disk? Answer in a form a human can read at a glance, with the unit printed right on the number.
prompt: student@linuxcamp:~/intercept$ answer: du -h logs/bulk.log output: 12K logs/bulk.log hint: A unit on the number means the human-readable flag. Point du -h at logs/bulk.log.
12K, unit attached. You now answer both classic size questions from memory: -b when someone wants exact bytes, -h when someone wants a readable on-disk figure.
Last one, and it combines two moves. Report the exact byte sizes of both intel/haiku.txt and intel/pangram.txt, in that order, using a single du command.
prompt: student@linuxcamp:~/intercept$ answer: du -b intel/haiku.txt intel/pangram.txt output: 75 intel/haiku.txt 44 intel/pangram.txt hint: The bytes flag, then both paths separated by a space: du -b intel/haiku.txt intel/pangram.txt
75 bytes and 44 bytes, one line each, one command. Three challenges, zero scaffolding: you are reaching for du and its flags from memory now, which is exactly what the capstone machine asks of you.
You earned this cheat sheet. Every row is a form of du you met in this lesson:
The one distinction to keep straight: du -b is exact bytes, plain du is rounded disk blocks. A disk hands out space in fixed chunks, so the on-disk size is almost always a little larger than the content. When you need the honest count, use -b. When you need to know what the disk is really carrying, use plain du or du -h.
On a nearly full disk, du -sh * inside a folder weighs every item in it at once and shows you the culprits in one screen. It is the classic first move when you are hunting for what ate the space.
The practice terminal has shown you how du weighs files and folders. The Reading Files module ends with one real Linux machine, and that is where you weigh them for real.
In the Reading Files capstone mission, a Linux VM boots just for you on the same intercept filesystem. You get objectives that use exactly what you ran here: plain du for disk blocks, -b for exact bytes, -h to make it readable, and -sh for a folder's one-line total. One difference from here: the lab shows no commands. You read the objective, you recall the flag, you type it. That recall is what makes it stick.
Finish the other Reading Files lessons, then go weigh the disk for real.
Practice du in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.