如何在创建文件系统时选择/知道要使用的块大小？是否有特定文件系统的特定块大小值被认为对该特定文件系统最有效？
假设我为文件系统选择了一个大的块大小,显然它会为大文件快速写入/读取数据.对于较小的文件,它会创建空间碎片(如果我错了,请纠正我).那么哪些应用程序通常使用大fs块大小,哪些应用程序使用小块大小？
块大小选择是否也会影响使用哪个文件系统？因此,对于特定的块大小,FS性能在一个FS(比如ext3)上更好,而对其他FS(例如ext2或vxfs或同一个os的任何fs)不太好？
解决方法
由于现代文件系统将使用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实现有效的一般经验法则,您应该将块大小保留为默认值,除非您有特定的理由假设(或者,更好的是,测试数据显示)选择非任何类型的好处 – 默认块大小.
