選擇文件系統塊大小
考慮 unix/linux/bsdunix 特定的文件系統：
在創建文件系統時如何選擇/知道要使用的塊大小？特定文件系統是否有任何特定的塊大小值被認為對該特定文件系統最有效？
假設我正在為我的文件系統選擇一個大塊大小，顯然它將為大文件快速寫入/讀取數據。對於較小的文件，它會產生空間碎片（如果我錯了，請糾正我）。那麼哪些應用一般使用較大的 fs 塊大小，哪些應用使用較小的塊大小呢？
塊大小選擇是否也會影響使用哪個文件系統？那麼對於特定的塊大小來說，FS 性能對於一個 FS（比如 ext3）更好，而對於其他 FS（比如 ext2 或 vxfs 或相同作業系統的任何 fs）來說不是那麼好？
塊大小是舊文件系統中的一種產物，其中記憶體和儲存是珍貴的物品，因此即使是指向數據的指針也必須進行大小優化。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 實現都有效的一般經驗法則，您應該將塊大小保留為預設值，除非您有特定理由假設（或者更好的是，測試數據顯示）選擇非-預設塊大小。
