0

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?

TEEBQNE
  • 6,104
  • 3
  • 20
  • 37
  • Cannot reproduce. What system and directory are you doing this on? Try running just the find command without grep and head to verify you're finding the files you're expecting. – virullius Oct 29 '18 at 18:15
  • Now able to reproduce this at root directory. – virullius Oct 29 '18 at 18:21
  • @mjb2kmn Yep sorry forgot to add the directory I was searching for. It is the root. Updated the question. – TEEBQNE Oct 29 '18 at 18:23
  • Is this the number you're getting: 140737477905152 ? – virullius Oct 29 '18 at 18:27
  • @mjb2kmn Around there yes. I'm getting 140737477884672 – TEEBQNE Oct 29 '18 at 18:32
  • That is a bogus result. It is the reported size of `/proc/kcore` which is a pseudo-file which represents addressable memory. Check out `man proc` and search for `kcore` for (little) more info. – virullius Oct 29 '18 at 18:47
  • @mjb2kmn I'm instead now using find / 2>/dev/null -user root -type f -not -name kcore -mmin -1 -exec du -ch {} + | grep total | head -1. I think the -ch was not working as the data being sent to it was too large to print? It now works as intended if I ignore the kcore. Thanks! – TEEBQNE Oct 29 '18 at 19:17

2 Answers2

0

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.

virullius
  • 939
  • 6
  • 17
0

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

Community
  • 1
  • 1
kenlukas
  • 3,616
  • 9
  • 25
  • 36
  • Thanks for this! I went ahead and ran the command I was running but used -not -name kcore and it returns a more reasonable output. The human readable option -ch also returns a value. I'm guessing with the kcore, the value was too large for the huaman readable to print? Not too sure. – TEEBQNE Oct 29 '18 at 19:30