前几天我遇到了一个有趣的情况。我在 /backup 上安装了一个 1TB NFS 文件系统。df报告的总大小约为 1TB，符合预期。
但是，du -csh .在 /backup/.snapshot 目录中运行报告了 3.0 TB 的数据。
我从未见过 du 产生的输出总大小大于安装点。此 NFS 共享由 NetApp 设备提供。 .snapshot 目录由 NetApp 创建，据悉，配置为使用 5% 的空间。 （当然，不可能使用 300% 的空间）
这是 Linux 问题、NFS 问题、NetApp 问题还是其他问题？我还可以提供哪些其他数据？
操作系统是CentOS 6。
答案1
我已经有一段时间没有使用 NetApp 了，所以我无法以绝对权威的方式回答，但我可以为此类行为提供解释。
听起来它的运行方式与 Linux 的 LVM 运行方式非常相似。假设您有一个 1TB 的物理磁盘，其中 100% 映射到 LVM 卷组。现在，您在该卷组上创建一个 100GB 的逻辑卷。您执行一些操作，在其上放置一些文件等。然后创建该逻辑卷的快照。现在，逻辑卷上修改的任何文件（实际上是块）都会被复制，以便快照可以访问原始数据。但您也可以拍摄此快照并将其像普通卷一样安装。如果你挂载它，你现在已经挂载了 2 个 100GB 的文件系统。但是这两个文件系统共享相同的数据（物理卷块），直到其中一个文件系统上的数据发生更改。
因此，NetApp 可能会做的是让您通过其/backup/.snapshot目录访问这些快照。分析时，每个快照看起来与原始卷大小相同。
这可能看起来很奇怪，但它是完全合法的（就 NFS、内核等而言）。当您运行 时df，您的系统会发出 NFS 调用来说明“此文件系统有多大”，远程系统可以根据需要进行响应。然后，当您执行 a 时du，您的系统会发出 NFS 调用来说明“此文件有多大”，远程系统可以根据需要进行响应。
您还可以对稀疏文件执行类似（但不相同）的操作。据说该文件占用的空间比实际占用的空间多。
如今，有许多先进的方法可以节省文件系统的空间。 “我有多少空间”或“该文件占用多少空间”的问题并不总是有简单的答案。您可以拥有快照、重复数据删除、透明压缩等功能。