考虑 unix/linux/bsdunix 特定的文件系统：
在创建文件系统时，如何选择/了解要使用的块大小？特定文件系统是否有任何特定的块大小值，该值被认为是该特定文件系统最有效的？
假设我为文件系统选择了较大的块大小，显然，对于大文件来说，它将快速写入/读取数据。对于较小的文件，它将产生空间碎片（如果我错了，请纠正我）。那么哪些应用程序通常使用较大的文件系统块大小，哪些应用程序使用较小的块大小？
另外，块大小选择是否会影响要使用的文件系统？那么，对于特定的块大小，FS 性能是否在一种 FS（例如 ext3）上更好，而在另一种 FS（例如 ext2 或 vxfs 或相同操作系统的任何 fs）上则不太好？
答案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 实现的一般经验法则，您应该将块大小保留为默认值，除非您有特定的理由假设（或者更好的是，测试数据显示）选择非默认块大小会带来任何好处。
答案2
对于较新的采用 SSD 的系统，大多数最新构建的 SSD 使用 4K 块大小的效果比使用 512B 块大小的效果好得多，主要是因为 SSD 使用的 NAND 闪存页面大小至少为 4K。