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

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。我还试着去掉了头-1，以为我抓错了数据，但每次打印出来的数据都是0。为什么会这样？有没有其他方法可以同时使用字节查找和人类可读打印输出来获取所有文件的总大小？

Answer 1

将-xdev选项用于find命令以排除其他文件系统。

我还没有解释原因，但我认为这与tmpfs和devtmpfs文件系统(如/proc(有关。

Answer 2

当我运行您的场景时，我得到了相同的结果，因为-b选项增加了/proc/kcore的大小

procfs有点黑暗魔法；里面没有真实的文件。它看起来像一个文件系统，行为起来像一个系统，而且是一个系统。但不是存储在磁盘(或其他地方(上的。

/proc/kcore是一个直接映射到虚拟内存中每个可用字节的文件。。。我对细节不是很清楚；128TB来自Linux，它为虚拟内存分配了64位中的47位。

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

0/proc/kcore

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

1407374866266368/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文件是巨大的

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