在通过 浏览文件夹时ncdu，我注意到文件的表观大小有时比实际磁盘使用量大得多。通过示例ncdu，然后a在显示磁盘使用情况和显示明显情况之间切换，然后i显示更多详细信息：
有人告诉我，这可能是由于某些自动过程只将一小部分数据保留在“快速”层中，并将其余数据保留在较慢的位置（例如 AWS S3）。我该如何检查？
作为建议经过克里斯·唐hexdump，这是该文件上运行的部分输出：
这似乎表明该文件并不稀疏。
作为建议经过阿乔姆·S·塔什基诺夫，文件系统是光泽（用 进行检查sudo df -T）。
答案1
这是常见（但不明显）的行为分层存储系统，例如 Lustre。ncdu和其他稀疏测量工具通常依赖于给出的值st_blocks响应一个stat称呼。在历史上的非写时复制文件系统上，明显的行为是我们所期望的：每个文件在磁盘上至少占据其包含的非零数据的确切数量，因此st_blocks至少指示数量文件中存储的实际非零数据。在 Lustre 中，st_blocks代表前端系统上使用的存储，而不是文件中存储的数据总量。
只有一个小例外：“已发布”文件（其内容完全从前端存储中删除）表明它们占用 512 字节，而不是 0。这是已实现的作为工具问题的解决方法，例如tar这将st_blocks完全跳过读取带有 0 的文件，从而导致基于 Lustre 的文件系统上的数据丢失（使用稀疏文件检测归档已发布的文件，这在备份场景中很常见，最终将根本不存储任何数据）。当一个文件表明它占用 512 字节时，工具必须读取它（或使用fiemapioctl 等) 准确确定其包含的内容；在 Lustre 上，此类操作会提示从存储在层次结构中的任何位置检索文件数据。
对于大文件，将整个文件恢复到前端存储是不寻常的，这就是为什么在某些情况下您最终只会得到部分“占用的块计数”。