Two separate GNU du measurements can add up to more than one combined measurement of the same paths when hard links refer to the same file. By default, GNU du counts only one hard link to a file during a run. Separate invocations do not share that accounting history. Before treating different totals as corruption or a broken monitoring agent, make the measurement scope and counting rule explicit.
One file can appear under more than one name
A hard link is another directory entry referring to the same underlying file, not an independent copy of its data. If two measured paths contain names for the same file, counting the data once and attributing it to each name answer different questions.
The GNU Coreutils manual states that only one hard link is counted by default and that argument order can affect which entries and numbers are reported. This article addresses that accounting behaviour. It is not a general procedure for measuring snapshot-exclusive space or predicting exactly how much space a deletion will release.
Compare separate and combined measurements
The following commands assume GNU Coreutils on Linux. In an authorised, small test directory, suppose two existing regular-file names, first.bin and second.bin, are hard links to the same file. These examples only inspect those paths. They do not create, overwrite or delete files.
du -B1 -- first.bin
du -B1 -- second.bin
Each command starts a fresh process. Each can therefore report the file’s allocated usage without knowing that you measured another name in the previous command. Adding the two printed values yourself can count the same file twice.
Now request one combined measurement:
du -B1 -c -- first.bin second.bin
In this run, GNU du can recognise the repeated hard-linked file and count its storage only once in the total. A repeated file argument may not receive its own output line under default counting; do not interpret the missing line as a missing file. Reverse the argument order to see how attribution changes:
du -B1 -c -- second.bin first.bin
The first name encountered can receive the charge. For this two-name example, changing order changes attribution, not the fact that the shared file should be counted once under the default rule. Real directory trees also include directory storage and other files, so their totals need not equal a simple two-file illustration.
Use count-links only when you want repeated attribution
GNU du provides --count-links, also spelled lowercase -l, to count files even when they have already appeared as hard links. Compare:
du -B1 -c --count-links -- first.bin second.bin
This intentionally charges the shared file for both names. It can be useful when a report wants per-path attribution, but it is not evidence that two independent copies occupy separate blocks. Do not confuse lowercase -l with uppercase -L: uppercase changes symbolic-link dereferencing and answers a different question.
For a storage report, document whether the objective is a combined estimate across all selected paths or independent attribution for each path. Keep that choice consistent across reporting periods. A dashboard built from separate du runs can disagree with a single combined command even when neither command failed.
Check the premise before explaining the difference
If you do not know whether the paths are hard links, inspect them with GNU stat:
stat -c 'device=%d inode=%i links=%h name=%n' -- first.bin second.bin
For this regular-file example, matching device and inode values identify the same file on that filesystem. The inode number alone is insufficient across different filesystems. A matching file size or identical filename does not establish hard-link identity.
Also check for permission errors, changing files and differences in the selected directories. Do not hide error output just to produce a clean report. If one scan could not read part of the tree, treat its total as incomplete rather than comparing it as a complete inventory.
Know what the numbers cannot establish
-B1 expresses reported allocated usage in byte units; it does not switch to apparent file length. Sparse-file sizing is a separate issue. For a different storage troubleshooting task, see why journal cleanup may not reduce disk usage as expected. Both investigations benefit from checking what the measurement actually represents.
GNU’s manual also warns that copy-on-write sharing, compression and operating-system reporting can make du an imperfect measure of underlying device consumption. Hard-link-aware counting does not solve all filesystem accounting questions. No command here justifies deleting backups or predicts immediate reclaimed space.
Quick review checklist and source
- Use the same paths, units and options when comparing results.
- Record whether paths were measured together or in separate invocations.
- Check device and inode identity before blaming hard links.
- Choose default counting or count-links deliberately.
- Keep errors and avoid deletion-based experiments on production data.
The authoritative source is the GNU Coreutils manual source, specifically the du and stat invocation sections. Consult your installed manual too if your distribution ships a different release.
This tutorial is for educational purposes. Test carefully before production use. The site owner is not responsible for misuse, damage, data loss or production issues.



