为什么`du`的输出通常与`du -b`如此不同答案

【问题标题】：why is the output of `du` often so different from `du -b`为什么`du`的输出通常与`du -b`如此不同
【发布时间】：2026-02-18 00:40:01
【问题描述】：

为什么du 的输出经常与du -b 如此不同？ -b 是 --apparent-size --block-size=1 的简写。大多数情况下，仅使用 --apparent-size 会给我相同的结果，但 --block-size=1 似乎可以解决问题。我想知道输出是否正确，我想要哪些数字？（即实际文件大小，如果复制到另一个存储设备）

【问题讨论】：

为什么投反对票？这看起来是一个非常好的问题。如果您要对问题或答案投反对票，请礼貌地发表评论，以便每个人都可以学到一些东西。匿名投反对票是一个潜在的教学时刻。
@Pete：可能是因为这与 * 无关。我希望更多的高声誉用户会注意到。
ServerFault相关问题：serverfault.com/questions/290088/…

标签： linux filesystems filesize du

【解决方案1】：

表观大小是您的应用程序认为文件中的字节数。如果您决定通过 FTP 或 HTTP 发送文件，它将通过网络传输的数据量（不包括协议头）。这也是cat theFile | wc -c 的结果，以及如果您使用mmap 加载整个文件所占用的地址空间量。

磁盘使用量是因为您的文件占用了该空间而无法用于其他用途的空间量。

在大多数情况下，表观大小小于磁盘使用量，因为磁盘使用量计算文件最后（部分）块的完整大小，而表观大小仅计算最后一个块中的数据。然而，当你有一个稀疏文件时，表观大小会更大（当你在文件末尾寻找某个地方时会创建稀疏文件，然后在那里写一些东西——操作系统不会费心创建大量填充零的块—— - 它只为您决定写入的文件部分创建一个块）。

【讨论】：

谢谢！这是一个彻底的解释。那我为什么需要--block-size=1 才能拥有与wc -c theFile 相同的输出（保存cat 进程）。当我指定 -h、-k、-m、-B1 等时，看起来 du 只输出正确的字节数？但也许这真的是另一个问题？ du 默认输出块使用，而不是字节使用？
很好的解释，但没有谈论问题中出现的--block-size=1 -1。

【解决方案2】：

比较（例如）du -bm 和 du -m。

-b 设置 --apparent-size --block-size=1，但随后m 将块大小覆盖为1M。

-bh 与 -h 的相似之处： -bh 表示 --apparent-size --block-size=1 --human-readable，h 再次覆盖该块大小。

【讨论】：

如果仔细阅读问题，这一定是正确答案。重点必须是--block-size 通常默认不是1（即du 没有任何选项），而是1024 或512。--apparent-size 与-b 的副作用无关。
感谢您的提示，这比--apparent-size 短得多。

【解决方案3】：

最小块粒度示例

让我们玩一下看看发生了什么。

mount 告诉我我在一个安装在 / 的 ext4 分区上。

I find its block size 与：

stat -fc %s .

给出：

现在让我们创建一些大小为1 4095 4096 4097的文件：

#!/usr/bin/env bash
for size in 1 4095 4096 4097; do
  dd if=/dev/zero of=f bs=1 count="${size}" status=none
  echo "size     ${size}"
  echo "real     $(du --block-size=1 f)"
  echo "apparent $(du --block-size=1 --apparent-size f)"
  echo
done

结果是：

size     1
real     4096   f
apparent 1      f

size     4095
real     4096   f
apparent 4095   f

size     4096
real     4096   f
apparent 4096   f

size     4097
real     8192   f
apparent 4097   f

所以我们看到任何低于或等于4096 的东西实际上占用了4096 字节。

然后，一旦我们越过4097，它就会上升到8192，即2 * 4096。

很明显，磁盘总是将数据存储在4096字节的块边界处。

稀疏文件会怎样？

我没有调查确切的表示是什么，但很明显--apparent 确实考虑到了这一点。

这可能导致表面上的大小大于实际的磁盘使用量。

例如：

dd seek=1G if=/dev/zero of=f bs=1 count=1 status=none
du --block-size=1 f
du --block-size=1 --apparent f

给予：

8192    f
1073741825      f

如果我想存储一堆小文件怎么办？

一些可能性是：

使用数据库而不是文件系统：Database vs File system storage
使用支持block suballocation的文件系统

参考书目：

在 Ubuntu 16.04 中测试。

【讨论】：

【解决方案4】：

因为默认情况下 du 给出的磁盘使用量与文件大小相同或更大。正如 --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

【讨论】：

那么“表观尺寸”到底是什么？而我遇到的恰恰相反：表观大小几乎总是比磁盘使用量高几个数量级
实际上默认情况下，在启用压缩的分区上它也可以更小。

【解决方案5】：

文件和文件夹有它们的实际大小和磁盘上的大小。

--apparent-size 是文件或文件夹的实际大小
size on disk 是文件或文件夹在磁盘上占用的字节数。仅使用 du 时也是如此。

如果您遇到表观大小几乎总是比磁盘使用量高几个数量级，那么这意味着您有很多（“稀疏”）文件包含内部碎片或间接块。

【讨论】：