为什么“ du --apparent-size”有时会偏离90％以上？

我正在开发一个构建Pacman软件包的软件（基本上是带有一些特殊元数据文件的tarball）。测试套件将生成一些程序包，然后将结果程序包与记录的预期结果进行比较。

程序包中记录的元数据中的字段之一是程序包的安装大小，该大小由du -s --apparent-size在将其压缩之前在根目录上运行确定。

所有这些在我开发的本地Arch Linux机器上都可以正常工作。每次运行测试时，都会精确复制这些软件包，包括以字节为单位的安装大小（甚至不是千字节，字节！）。

现在，我还在Travis上启用了此测试，据我所知，它在基于Ubuntu-12.04的容器上运行（据我对Travis文档的了解）。在那里，测试大部分时间都通过了。大多数时候。有时，它计算出的安装大小减少了80-99％。

这是一个测试失败的示例：https : //travis-ci.org/holocm/holo/builds/89326780（该测试成功之前。）相关的区别之一是

@@ -37,7 +37,7 @@
             pkgdesc = my foo bar package
             url = 
             packager = Unknown Packager
-            size = 37728
+            size = 1464
             arch = any
             license = custom:none
             replaces = foo-bar<2.1

令人费解的是，它仅在某些时间发生，没有明显的模式。测试会像往常一样排列相同的文件，du -s --apparent-size在结果树上运行，并得出完全错误的结果。我尝试在Ubuntu 12.04 VM上重现此错误，虽然我看到它出现一次或两次，但我看不到那里出现任何可以帮助我重现此问题的模式。

也许有人在想什么可能导致此问题？

编辑：哦，实际上我观察到一种模式。du每个测试用例运行一次。如果第一个测试用例失败，则此运行中的所有测试用例都将失败。

linux ubuntu disk-usage

— 斯蒂芬·马耶夫斯基（Stefan Majewsky）
source

为了明确起见，所讨论的文件系统树中的所有条目都是纯连续文件，符号链接和目录。没有稀疏文件。没有设备文件，FIFO或任何其他时髦的业务。

— Stefan Majewsky

什么是文件系统？

— 马克·瓦格纳

@Mark Wagner：根据docs.travis-ci.com/user/workers/container-based-infrastructure

— Stefan Majewsky

可能的情况：（1）报告的大小是正确的，但是在某些情况下，其他操作还会剩余一些陈旧的文件（2）不确定AUFS，但是在NFS中，已删除的陈旧文件将重命名为.nfsNNNNNNNN，这些可能会占用大小不一致。您如何确定报告的尺寸不正确？您可以在各个子目录和文件上尝试du，以便检查不一致的确切位置吗？

— 2016年

您遇到的问题是AUFS。...检查与之相关的问题，检查其不在最新内核中的原因，检查其“稳定性”，检查其“ POSIX完整性”。

— Hvisage '16

好吧，@ derobert提示我将其作为答案

您遇到的问题是AUFS。...检查与之相关的问题，检查其不在最新内核中的原因，检查其“稳定性”，检查其“ POSIX完整性”。– Hvisage 1月24日20:55

— Hvisage
source