为什么 "find -mmin -1 -exec du -cb {} + | grep total | head -1" 和 "find -mmin -1 -exec du -ch {} + | grep total | head -1" 不同

Question

当我运行命令时：

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

我得到了预期的相当大的字节数。

但是，当我运行相同的命令但使用人类可读的而不是字节时，如：

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

我得到 0。我还尝试删除 head -1 认为我抓取了错误的数据，但每次打印出来的都是 0。为什么是这样？是否有替代方法来获取使用 find 找到的所有文件的总大小，包括字节和人类可读的打印输出？

Answer 1

使用 -xdev 选项到 find 命令排除其他文件系统。

我还没有解释为什么，但我认为这与 tmpfs 和 devtmpfs 文件系统有关，例如 /proc.

Answer 2

当我运行你的场景时我得到了相同的结果，因为 -b 选项增加了 /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.

当我为 du 使用 -ch 参数时，它显示 /proc/kcore 为 0:

0 /proc/kcore

但是当我使用 -cb 时，它显示我的 /proc/kcore 为：

140737486266368 /proc/kcore

这是因为 -b 选项：

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

和--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

参考文献：

/proc kcore file is huge

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

为什么 "find -mmin -1 -exec du -cb {} + | grep total | head -1" 和 "find -mmin -1 -exec du -ch {} + | grep total | head -1" 不同

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

linux

bash

grep

exec

find