选择文件系统块大小

Question

考虑到 unix/linux/bsdunix 特定的文件系统：

在创建文件系统时如何选择/知道要使用的块大小？是否有任何特定文件系统的特定块大小值被认为对该特定文件系统最有效？

假设我为我的文件系统选择了一个大块大小，显然它会为大文件快速写入/读取数据。对于较小的文件，它会产生空间碎片（如果我错了，请纠正我）。那么哪些应用程序一般使用大的 fs 块大小，哪些应用程序使用小块大小呢？

块大小选择对使用哪个文件系统也有影响吗？那么对于特定的块大小，FS 性能对于一个 FS（比如 ext3）来说更好，而对于其他 FS（比如 ext2 或 vxfs 或相同操作系统的任何 fs）则不是那么好？

Answer 1

块大小是过去文件系统时代的产物，在那里内存和存储是宝贵的财富，因此即使是指向数据的指针也必须进行大小优化。MS-DOS 为早期版本的 FAT 使用 12 位宽指针，因此允许管理多达 2^12 = 4096 个块（或文件）。由于文件系统的最大大小固有地限制为(max_block_size)x (max_block_number)，“正确”的块大小一直是一个问题，您必须考虑您的总文件系统大小以及通过选择将浪费的空间量更大的块大小。

由于现代文件系统将使用 48 位 (ext4)、64 位 (NTFS、BTRFS) 甚至 128 位 (ZFS) 指针，允许使用巨大的（就块数而言）文件系统，选择块大小已成为除非您有特定的应用程序并希望针对它进行优化，否则这不是一个重要的问题。例子可能是

• 具有大块的块设备，您不希望不同的文件“共享”单个物理块作为性能优化 - 在这种情况下选择与物理设备块大小匹配的大文件系统块
• 日志记录软件将写入大量具有固定大小的文件，您希望通过选择与您的典型文件大小匹配的块大小来优化存储利用率

正如您特别要求 ext2/3 - 到目前为止，这些是使用 32 位指针的相当陈旧的文件系统，因此对于大型设备，您可能必须经历相同的“最大文件系统大小与浪费的空间”考虑因素我写过早些时候。

文件系统性能可能会受到用于单个文件的大量块的影响，因此更大的块大小可能是有意义的。具体来说，ext2 的块引用数量相当有限，可以直接与 inode 一起存储，并且必须通过四层链表来引用消耗大量块的文件：

很明显，具有较少块的文件将需要较少的参考层，因此理论上允许更快的访问。话虽如此，智能缓存很可能在实践中掩盖了这个问题的大部分性能方面。

另一个经常用于支持更大块的论点是碎片化。如果您的文件不断增长（如日志或数据库），则文件系统块大小较小会导致磁盘上出现更多数据碎片，从而降低顺序读取较大数据块的几率。虽然这本质上是正确的，但您应该始终记住，在为多个进程（线程/用户）提供服务的 I/O 子系统上，对于通用应用程序而言，顺序数据访问是极不可能的。如果您对存储进行了虚拟化，则更是如此。因此，除了某些极端情况外，碎片本身不足以作为选择更大块大小的理由。

作为适用于任何健全的 FS 实现的一般经验法则，您应该将块大小保留为默认值，除非您有特定的理由假设（或者，更好的是，测试数据显示）选择非-默认块大小。