我在 Ubuntu 上有一个目录，其中包含 262144 个文件。每个文件都是一个 25x25 的 png 图像。这些文件的平均大小约为 1.14kb，没有一个文件大于 2kb。然而，这个目录占用了 3.1GB 的磁盘空间。这怎么可能呢？根据我的计算，这个目录应该使用262144 * 1140 = 298844160 bytes，也就是0.298844 GB。
以下是我获取此信息所遵循的步骤。
我运行程序ls -1 -f | wc -l来计算目录中的文件数量。这将返回262146（即262144 + 1 + 1和.）..。
接下来我运行find . -size +2k，结果就是.。
最后我运行了du -sh culprit_directory，结果显示了3.1G culprit_directory。
我认为可能会发生两件事：
- Ubuntu 需要额外的空间来存储包含大量非常小的文件的目录。有可能，但是要达到一个数量级吗？
- 我的计算有误，这是目录的预期大小。也可能如此，但我看不出我在哪里犯了这个错误。
如果有谁对 Ubuntu 内部文件存储有更多经验，可以给我一些建议，我将不胜感激。
编辑：
我添加了一个 png 文件。这个是591 bytes尺寸。
编辑：
感谢下面 muru 的有益评论，我已确定每个文件实际上占用12KB磁盘空间，即使它仅包含几百个字节。使用新数字，我们得到262144 * 12000 = 3145728000，这给了我们3.145728GB。
我想我的新问题是如何避免每个文件占用太多空间？
答案1
回答后续问题，在这些情况下，最简单的做法可能是创建一个小型的临时文件系统并循环挂载它。就像这样：
$ dd if=/dev/zero of=imgdisk.img bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.425628 s, 1.3 GB/s
$ du -h imgdisk.img
513M imgdisk.img
$ mkfs.ext4 -b 2048 imgdisk.img
mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done
Creating filesystem with 262144 2k blocks and 32768 inodes
Filesystem UUID: 8837a733-6b75-4326-bb72-9372538653ad
Superblock backups stored on blocks:
16384, 49152, 81920, 114688, 147456
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
$ mkdir imgmount
$ sudo mount imgdisk.img imgmount -o loop
$ ls imgmount/
lost+found
复制其中的图像（大小可能与只是对您的文件来说太小；将 512 改为 513（如果是这样），则umount循环文件系统，将其挂载到包含所有图像的目录中。如果可行，umount则从那里删除原始图像，进行编辑，/etc/fstab以便将循环文件系统挂载到正确的位置，mount -a这样您就设置好了。
编辑：您-b 1024也可以使用它来代替 2048。
答案2
不同的软件以两种方式报告不同的磁盘空间使用情况统计信息。文件的大小可以是文件中的字节数，而“物理大小”可以是该文件使用的簇大小的总和。物理大小或“簇大小”是操作系统在引用磁盘上使用的空间时跟踪的最小块。因此，如果您有一个包含 1 个字节的文件，并且簇大小为 8 千字节，则该文件至少使用 1 个簇，即 8kb。
即使磁盘大小增加并且簇大小增加到 32kb 或 64kb，浪费的磁盘空间通常并不是一个问题。
guess my new question would be how to avoid each file using so much space?
将不常用的文件放入存档文件（如 .zip 文件）。操作系统对于可以跟踪的集群数量有限制。
也许其他人可以解释几个操作系统的集群大小限制。