du
does a depth-first traversal of the given tree. By default, it shows the usage of every directory tree, showing the inclusive disk usage of each:
$ du ~
4 /home/bob/Videos
40 /home/bob/.cache/abrt
43284 /home/bob/.cache/mozilla/firefox
43288 /home/bob/.cache/mozilla
12 /home/bob/.cache/imsettings
48340 /home/bob/.cache
4 /home/bob/Documents
48348 /home/bob
If given the -a
option, it will additionally show the size of every file.
With the -s
option, it will show just the total size of each argument file or directory tree.
$ du -s ~
48348 /home/bob
$ du -s ~/*
4 /home/bob/Videos
4 /home/bob/Documents
So, when you ran
$ du -b ~ | wc -l
15041
$ du -b ~ | sort -n | head -n 15040 | cut -f 1 | \
perl -ne 'BEGIN{$i=0;$i+=$_;END{print $i.qq|\n|;}'
12735983847
you were summing up the size of everything under your home directory - multiple times, unfortunately, because the size reported on each line is inclusive of all subdirectories - but because you omitted the final line of du's output, which would be the line for /home/steven
, du
didn't count the size of any of the regular files in the top level of your home directory. So the sum didn't include your very large .xsession-errors
file.
And when you ran
du -sb ~ returns 91296460205, but the sum of du -sb ~/* is only 1690166532
your du -sb ~/*
output didn't include any files or directories in your home directory that begin with .
.
Both du ~ | tail -1
and du -s ~
should do a reasonable job of showing your home directory's disk usage (not including deleted-but-open files, of course), but if you want to sum up all the file sizes without relying on du
, you can do something like this (assuming a modern find
that supports the printf %s
format to show the size in bytes):
find ~ -type f -printf '%s\n' | perl -ne 'BEGIN{$i=0;$i+=$_;END{print $i.qq|\n|;}'
the file /etc/fstab is executed regardless of the user, I believe, hence I presume that the partitions are always mounted.
Yes, but there is an interaction with the use of ecryptfs. fstab is processed at boot time. The ecryptfs mount is activated at login time, after you enter your decryption password. The ecryptfs mount shown in the question will mask any existing mount on /home/user1
, for example. Note, this would be a bit more apparent when you use the recommended findmnt
tool to show the hierarchy of mounts. (The mount
output is simpler for getting the complete list of mount options though).
So, you need to mount your storage filesystem outside any user's home directory. Be aware that files outside your home directory will not be encrypted, unless you work out how to do so manually. You can create a symbolic link to it if desired (e.g. ln -s /storage /home/user2/storage
). The way it's set up right now does not make any sense, and could break other things as well (I'm suspicious about the ordering of unmounts on shutdown).
Note the question was already confusing to analyze since it lacked the full output from the df
commands. There's another corner case, that df /dev/sda1
will show the usage of /dev
if sda1
is not mounted. If you look at strace df /dev/sda8
, you will see that it does not access the device node; it looks up the directory from the mounts, and then calls statfs("/home", ...)
. I would prefer to run df -h /home
myself...
...I don't necessarily expect the output would be any less confusing when there's an over-mounted filesystem like this though. The omission or -
result for sda13 (depending on -a
option) suggests that df
has some code to detect the overmount case, but it's not working in all cases. EDIT: reported upstream.
Best Answer
The following will work with
GNU find
andawk
: