文件系統設計中的 Sectorsize有什麼用？

01-09

細看各個文件系統都會有sectorsize,扇區大小不是512位元組么[硬體會有區別？]，為什麼像Btrfs這樣的文件系統會設置成4096個位元組，另外文件系統設置扇區大小對於文件系統的讀寫具體有什麼樣的影響呢。

首先扇區大小不全是512位元組，理論上它可以是512/1024/2048/4096（這一點可以參考Linux源碼方fs/fat/inode.c: fat_fill_super）。

扇區大小與上面的文件系統沒有直接關係。

舉個例子：早期的iPod有些就是4096位元組扇區的，文件系統是FAT32。較新的硬碟也有一些是4096大小扇區的，它可以被格式化成NTFS/FAT32，具體用什麼完全取決於你自己。所以各個文件系統自己要負責記錄每個扇區的大小。

目前主要的兩種大小是512位元組和4096位元組，在這方面，是有一些相關的技術標準的：The Advent of Advanced Format

所以，你第一條的理解就是不正確的。512確實是大多數的值，但確實也有太多不是512位元組的。

BTRFS的具體情況我不了解，但是也沒聽說BTRFS強制要求扇區大小是4096吧？我猜應該是單個塊大小是4096位元組，這一點你要自己調查一下：Btrfs

據我所知大多數文件系統都支持非512位元組大小的硬體。

大扇區有一些好處：

1、大扇區有可能降低IOps數，讀寫同樣的數據，IO的次數可能降低，這樣有助於提高讀寫性能，因為硬體的IOps值都是有上限的。

2、4K扇區在x86平台正好是一個內存頁，方便內存的管理，不容易產生內存的碎片頁。

3、部分文件系統不支持（或者支持不好）超過2^32個扇區，如果按照512位元組算，正好是2TB，而如果是4096位元組扇區，則是16TB，這樣就可以在不使用GPT分區表的情況下使用現有文件系統訪問大硬碟了。

我發現提問者在幾個回合後還是沒有分清楚扇區大小（磁碟最小檢索單位大小）和簇大小（文件系統最小分配單元大小）的區別，導致問的是扇區大小，但實際上自己理解的是簇大小。

事實上這兩者可以沒有什麼關聯。扇區大小是硬體設計所定義的，是不可能被設置的，除非前面有個軟體進行轉換。

文件系統的簇大小則可以在很大程度上自定義，例如NTFS所支持的簇大小可以從512位元組到64KB。

文件系統的簇大小主要影響文件分配表的大小，過小的簇大小會導致過大的文件分配表，浪費磁碟空間和降低文件系統性能，甚至過小的簇大小會導致文件分配表達到限制從而讓文件系統無法支持更大的分區。

而過大的簇大小則在文件普遍太小的時候浪費磁碟空間，因為一個文件最少必須佔據一個簇（除非是零位元組有優化措施）。

問題中問的是文件系統中的最小操作單元，這個是在操作系統下創建文件系統時候（mkfs）指定的，linux創建文件系統默認都是4096，新建一個目錄直接看它的大小就是4096，當然用tune2fs一類的命令也可以看到。

至於在操作系統底層的存儲硬體，默認設置通常默認512，這個在陣列卡下面新建虛擬磁碟（通常是raid）的時候可以看到，當然也可以調整。網上有關於ssd硬碟優化，就是把這個默認值改為4096。

上面的參數都是在系統優化的時候才用到，主要看你的文件是小而多還是大而少，具體分析比較，適當調整（實際上還有許多其他的參數）。

此外一些大型程序本身也自己定義讀者最小單元，比如安裝資料庫的時候，比如創建邏輯卷的時候。基本原則是上層是下層的倍數，比如oracle資料庫默認8192剛好兩個4096，不過這些都是依賴於操作系統的值。

文件系統定義的記錄了Sectorsize，應該和底層具體大小還是可以區分開得，文件系統定義的Sectorsize可以理解成他的「最小分配單元」(Not sure),而磁碟實際的sectorsize,是它的基本IO單元

?也就是影響IOps的原因。

另外像Btrfs這樣比較新的文件系統直接把sectorsize設置成4k, 主要考慮到Btrfs本身的元數據大小就是4k的整數倍，考慮到新的存儲設備可能4k的扇區大小會成為主流，所以強制使用4k可以提高IOps 吧。

這些只是個人的一些理解，Sigh.