select文件系统块大小

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

如何在创build文件系统时select/知道使用哪个块大小？对于特定的文件系统，是否有特定的块大小值被认为是最有效的？

比方说，我正在为我的文件系统select一个较大的块大小，显然它会为大文件快速写入/读取数据。对于较小的文件，它会创build空间碎片（纠正我，如果我错了）。那么哪些应用程序通常使用大的fs块大小，哪些使用小块大小呢？

另外，块大小的select会影响使用哪种文件系统？那么对于一个特定的块大小，FS性能对于一个FS（比如说ext3）更好，对于其他FS（比如说ext2或者vxfs或者对于同一个os的任何fs）来说不是那么好？

块的大小是存储和存储都是珍贵物品的文件系统的古老产物，因此即使是指向数据的指针也必须进行大小优化。 MS-DOS为FAT的早期版本使用了12位宽指针，因此允许pipe理最多2 ^ 12 = 4096块（或文件）。由于文件系统的最大大小固有地限制在(max_block_size) x (max_block_number) ，所以“正确的”块大小是一个问题，您必须考虑文件系统的总大小和空间大小通过select更大的块大小来浪费。

由于现代文件系统将使用48位（ext4），64位（NTFS，BTRFS）甚至128位（ZFS）指针，从而允许巨大（按块数）文件系统，select块大小已成为less一个重要的问题，除非你有一个特定的应用程序，并希望优化它。例子可能是

块设备与大块不希望不同的文件“共享”一个物理块作为性能优化 – 大型文件系统块匹配物理设备块大小在这种情况下select
日志logging软件，它会写大量文件的固定大小，你想优化存储利用率，通过select块大小来匹配你的典型文件大小

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

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

inode和引用块

所以显然，一个块较less的文件将需要较less的参考层，因此理论上允许更快的访问。这就是说，智能caching可能会在实践中掩盖这个问题的大部分性能方面。

另一个经常被用来支持较大块的论点是碎片化 。如果文件连续增长（如日志或数据库），文件系统块大小会导致磁盘上的数据碎片增多，从而降低大数据块连续读取的几率。虽然这本质上是对的，但是您应该始终记住，在服务于多个进程（胎面/用户）的I / O子系统上，连续数据访问对于通用应用程序来说是不太可能的。如果你已经虚拟化你的存储，那更是如此。因此，碎片本身并不足以作为更大块尺寸select的理由，除了一些angular落案例。

作为一个通用的经验法则，任何理智的FS实现都是有效的，除非你有一个特定的理由来假设（或者更好的是testing数据显示）select非 – 默认块大小。

对于采用固态硬盘的更新系统，最近制造的固态硬盘在4K块大小方面效果要好于512B块大小，主要原因在于SSD使用的NAND闪存页面大小至less为4K。