Why “find -mmin -1 -exec du -cb {} + | grep total | head -1” and “find -mmin -1 -exec du -ch {} + | grep total | head -1” are different

Question

When I run the command:

find / 2>/dev/null -user root -type f -mmin -1 -exec du -cb {} + | grep total | head -1

I get a rather large number in bytes which is expected.

However, when I run the same command but with human-readable instead of bytes, as in:

find / 2>/dev/null -user root -type f -mmin -1 -exec du -ch {} + | grep total | head -1

I get 0. I also tried removing the head -1 thinking I was grabbing the wrong data, but every print out is 0 total. Why is this? Is there an alternative method to get the total size of all files found using find for both bytes and human-readable print outs?

Answer 1

Use -xdev option to find command to exclude other filesystems.

I don't have an explanation why yet, but I think this is related to tmpfs and devtmpfs filesystems such as /proc .

Answer 2

When I ran your scenario's I had the same results because the -b option adds in the size of /proc/kcore

procfs is a bit of dark magic; no files in it are real. It looks like a filesystem, acts like a filesystem, and is a filesystem. But not one that is stored on disk (or elsewhere).

/proc/kcore specifically is a file which maps directly to every available byte in your virtual memory ... I'm not absolutely clear on the details; the 128TB comes from Linux allocating 47ish bits of the 64bits available for virtual memory.

When I use the -ch argument for du it shows /proc/kcore as 0:

0 /proc/kcore

But when I use the -cb it shows my /proc/kcore as:

140737486266368 /proc/kcore

this is because the -b option:

-b, --bytes
equivalent to '--apparent-size --block-size=1'

and --apparent-size :

--apparent-size
print apparent sizes, rather than disk usage; although the apparent size is 
usually smaller, it may be larger due to holes in ('sparse') files, internal 
fragmentation, indirect blocks, and the like

References:

/proc kcore file is huge

https://linux.die.net/man/1/du