linux – 选择文件系统块大小

块大小是文件系统的历史中的一种工件,其中内存和存储是珍贵的商品,因此即使是指向数据的指针也必须进行大小优化. MS-DOS使用12位宽指针用于早期版本的FAT,因此允许管理多达2 ^ 12 = 4096个块(或文件).由于文件系统的最大大小固有地限制为(max_block_size)x(max_block_number),因此“右”块大小是一个问题,您必须考虑总文件系统大小和空间量.通过选择更大的块大小来浪费.

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

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

正如你特别要求ext2 / 3 – 现在这些是使用32位指针的相当老化的文件系统,所以对于大型设备,你可能必须运行相同的“最大文件系统大小与空间浪费”的考虑我写的关于早.

文件系统性能可能会受到用于单个文件的大量块的影响,因此更大的块大小可能有意义.具体来说,ext2具有相当有限数量的块引用,可以直接存储inode和消耗大量块would have to be referenced through four layers of linked lists的文件：

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

经常用于支持更大块的另一个论点是碎片化.如果您的文件不断增长(如日志或数据库),则文件系统块大小会导致磁盘上的数据碎片更多,从而降低了按顺序读取大块数据的几率.虽然这本质上是正确的,但您应该始终记住,在服务于多个进程(踏板/用户)的I / O子系统上,顺序数据访问对于通用应用程序来说极不可能.如果您虚拟化了存储空间,那就更是如此.因此,碎片本身不足以作为除了某些极端情况之外的所有块大小选择的理由.

作为对任何理智的FS实现有效的一般经验法则,您应该将块大小保留为默认值,除非您有特定的理由假设(或者,更好的是,测试数据显示)选择非任何类型的好处 – 默认块大小.