塊大小是文件系統的歷史中的一種工件,其中內存和存儲是珍貴的商品,因此即使是指向數據的指針也必須進行大小優化. 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實現有效的一般經驗法則,您應該將塊大小保留為默認值,除非您有特定的理由假設(或者,更好的是,測試數據顯示)選擇非任何類型的好處 – 默認塊大小.