HFS+ 文件系統有哪些缺陷和不足？

---

以下摘自「Mac OS X背後的故事（十一）Mac OS X文件系統的來龍去脈（上）」：

HFS+ 並不完美

　　HFS+ 自發布以來，幾乎每個發行版都有令人欣喜的改動。它也逐漸成為一個非常完善的文件系統。但 HFS+ 立足於 HFS 設計，HFS 已有 27 年的歷史，HFS+ 亦有 14 年歷史。這個文件系統有大多的歷史包袱，為考慮兼容性，這些陳舊的設計並不能被推翻重來。

　　HFS+ 基於 B- 樹實現，當查找 B- 樹中未使用的節點時，HFS+ 只能每次處理 16 位，原因是老 Mac 使用的 Motorola 的 68K 晶元原生支持 16 位的數據操作。但不管是 PowerPC 還是 Intel，寄存器都支持 256 位寬的寄存器。

　　HFS+ 的元數據（metadata）都以大位元組序保存，原因是 Motorola 的 68k 和後來 Mac 使用的 PowerPC 都使用大位元組序。但經過 Intel 遷移後，當今的 Mac 都使用 Intel 晶元，而 Intel 晶元是使用小位元組序的。因此每當數據讀取或存入時，還要經過小位元組序和大位元組序的轉換。遠古時期磁碟很慢，計算機處理器的速度也很低，因此進行一次磁碟操作會佔用較多的時間，HFS+ 的時間解析度為一秒，但當今的磁碟、處理器處理一次文件系統操作的時間遠小於一秒，因此所有主流磁碟文件系統的時間解析度都是一至數百納秒級別的。

　　HFS+ 的元數據有全局鎖，同一時間只有一個進程可以訪問更新文件系統。在單核處理器連手機平板都較少見到的當今，這種設計顯得很幼稚。

　　HFS+ 亦沒有稀疏文件的支持。例如我們在 SQL 中建立了一個資料庫，SQL 分配了 10 GB 的文件給這個資料庫，並且在文件頭和文件尾寫上一些位元組的數據。而由於我們還沒有給這個資料庫添加新的數據，所以這 10 GB 的文件除了頭尾外其他位元組都為 0。現代的文件系統基本都支持稀疏文件，也就是說，當處理這個資料庫操作時，事實上往磁碟寫入的數據只有那文件頭和文件尾的若干位元組。而 HFS+ 則需要把那些 0 也寫上，因此會完整寫入 10 GB 的數據，耗費長得多的時間。

　　此外，HFS+ 不具備元數據校驗功能、快照功能、寫入時複製功能、就地執行功能、邏輯卷管理功能等很多現代磁碟系統所具備的功能，也不能動態調整文件塊大小。這些功能的加入並不容易。

　　其中最要命的是，HFS+ 不像一些先進的文件系統，支持寫入時複製事務模型，也沒有快照和克隆。這使得用戶數據時時處於風險之中。例如由於因為斷電、內核崩潰等原因，文件系統上寫到一半的數據，小則導致個別文件損壞，大則導致整個文件系統崩潰。在生產領域，這樣不可靠的文件系統，很有可能帶來致命的災難。

---

Quite frankly, HFS+ is probably the worst filesystem ever. Christ what shit it is.

- Linus Torvalds

HFS+ 的另一個嚴重的缺（gong）陷（neng），是大小寫不敏感。

以下是在 HFS+ 上做的一個簡單實驗：

$ echo a &> a
$ echo b &> A
$ cat A
b
$ cat a
b


附上 Linus 對於 HFS+ 評論的原始連接。

---

推薦閱讀：