文 / 王越

HFS+和UFS檔案系統同時被引入早期的Mac OS X，隨著若干年的發展，HFS+提供的功能已超越UFS，使其在Mac OS X 10.5之後成為成為唯一正式的Mac OS X系統，但因為其揹負許多的歷史包袱，為考慮相容性，這些陳舊的設計並不能被推翻重來，所以蘋果開始祕密研發下一代的檔案系統。

著名BSD開發者Marshall Kirk McKusick

UFS：經典的Unix檔案系統

在Unix系統剛誕生的遠古時期，檔案系統被簡單地稱為FS。FS只包括啟動塊、超級塊（處於硬碟分割槽開頭用來儲存檔案系統資訊）、inodes（索引節點）及資料。FS檔案系統在Unix系統剛誕生時還能滿足新老客戶的需求，但隨著科學技術的進步，FS已不能符合現代檔案系統的需求，且會導致抖動等一系列問題。當時還是加州大學伯克利分校研究生，後成為著名BSD開發者Marshall Kirk McKusick在BSD 4.1b上承接傳統的FS檔案系統實現了FFS（

Fast File System），妥善地解決了這一難題，把先前整塊的磁碟檔案系統分為小塊，每塊包含自已的索引節點和資料，因而增加了檔案的區域性性，減少了尋道時間。由於Marshall Kirk McKusick的FFS檔案系統很好很強大，所以立即被各大Unix系統所使用。SunOS/Solaris、System V Release 4、HP-UX及Tru64 UNIX都使用它，也成為當今各BSD分支（FreeBSD、OpenBSD、NetBSD及DragonFlyBSD）的標準檔案系統。每個不同的系統，無論開源與否，又會在FFS檔案系統上增加各種擴充套件，這些擴充套件往往不互相相容，但神奇的是，大家又都使用和原版同樣的塊大小和資料塊寬度。因此在很大程度上，這些山寨版FFS檔案系統又相互相容，至少在一個作業系統上能對另一作業系統的檔案系統執行只讀操作。因此，FFS事實上已經成為Unix系統的標準檔案系統，故它有了一個更廣泛的稱謂——UFS（

Unix File System，即Unix檔案系統）。

UFS在後來的若干年又取得了長足的發展。Sun公司在Solaris 7系統中，給UFS提供了簡單的日誌功能。日誌檔案系統指在檔案系統發生變化時，先把相關的資訊寫入一個被稱為日誌的區域，然後再把變化寫入主檔案系統的檔案系統。在檔案系統發生故障（如核心崩潰或突然停電）時，日誌檔案系統更容易保持一致性，並且可以較快恢復。Marshall Kirk McKusick又實現了BSD一度引以為豪的Soft Update功能，來保證計算機掉電或系統崩潰時，通過使元資料按依賴順序更新來確保磁碟上總的檔案系統保持一致的實現機制。Soft Update的目標和日誌類似，但實現代價比日誌輕量許多。不過這項功能有所代價，主要是需要引入一個後臺FSCK檢查。

2009年，Jeff Roberson正式發表了對UFS的一項改進，為Soft Update加入了日誌功能，並消除了對FSCK的依賴，這項改進最終整合進了FreeBSD 9中。TrustedBSD專案又為BSD分支的檔案系統設計了ACL訪問控制表功能（Access Control Lists）。先前，Unix檔案系統的訪問控制是非常簡單的，其許可權管理分為三個不同的類別：使用者、同組使用者以及其他使用者，對每個類別，Unix檔案系統提供讀、寫、執行三種許可權的管理。這樣的許可管理過於粗糙，無法指定某一使用者訪問的許可權，也無法指定更為細緻的許可權內容（例如准許對一檔案實行刪除操作）。為解決這個問題，訪問控制表被增加到檔案系統中，使用以存取控制矩陣為基礎的存取控制方法。存取控制串列描述每一個檔案物件各自的存取控制，並記錄可對此物件進行存取的所有主體對物件的許可權。總之，UFS與時俱進，不斷增加新的功能。

HFS+：更現代的HFS

作為Mac OS X的老祖宗NeXTSTEP，因為基於BSD，所以自然也使用UFS。而老版的Mac OS則使用一個叫做HFS的檔案系統。HFS是一個比較古老且不思進取的檔案系統，因此，在20世紀90年代末已不能滿足當時的需要。在《Mac OS X背後的故事（一）》中我們提到，為了實現Mac OS的現代化，Copland專案被提出。Copland專案的子專案Sequoia旨在HFS的基礎上，加入現代檔案系統所必需的新功能，如大檔案支援、Unicode檔名支援、長檔名支援、32位檔案對映表支援等。Sequoia專案即成為後來熟知的HFS+，由Don Brady領導，這個團隊先花了6個月時間把HFS專案原本的Mac使用的68K處理器彙編碼改寫成C程式碼，然後逐漸加入新功能。

後來由於Copland被力挽狂瀾的Ellen Hancock給廢了，所以一些有用的更新，如HFS+即被整合到Mac OS 8.1中。在Mac OS X誕生初期，HFS+和UFS檔案系統同時被引入早期的Mac OS X中。不過由於HFS+根植Mac OS，缺乏Unix檔案系統所必需的功能，如符號連結、硬連結及其他各種POSIX相容性，所以HFS+開發組又花了一些工夫在不影響和Mac OS相容性的情況下引入了這些功能。由於HFS+是對HFS的擴充套件，故HFS+支援Mac OS至Mac OS X的平滑過渡，所以Mac OS X一直預設使用HFS+。但當時的UFS提供比HFS+更先進的功能，因此Mac OS X 10.0至10.4，也都支援把系統安裝在UFS系統上。

Mac OS X 10.0釋出後，蘋果不遺餘力地對HFS+進行大規模的擴充套件和維護，增加了很多UFS獨有的功能。這些新功能使得檔案系統更加安全穩定可靠。例如Mac OS X 10.2.2中，HFS+支援日誌。日誌功能在Mac OS X 10.2伺服器版中可以簡單地設定，但在普通桌面版中需要使用命令列進行操作。在Mac OS X 10.3中，帶日誌功能的HFS+（被稱為HFSJ，即HFS+ volume with journal）成為預設設定。Mac OS X 10.3亦增加名件名、目錄名區分大小寫及Unicode 3.2的支援。Mac OS X 10.4中，HFS+更是增加了ACL訪問控制表功能，提供更復雜的對傳統Unix檔案系統許可權的擴充套件。

檔案系統除了讓使用者供穩定地存放檔案這一目標以外，還是各項作業系統功能的基礎。Mac OS X每個大發行版都要增加數百項新功能，許多新功能嚴重依賴於檔案系統的實現。Mac OS X 10.3提供了FileVault來加密使用者檔案，因此使用者主目錄被儲存在一個HFS+檔案系統加密映象中。Mac OS X 10.4提供了系統內建的Spotlight桌面搜尋搜尋功能，能讓使用者對整個磁碟系統進行快速搜尋、隨打即顯。這項功能要求檔案系統提供任意長度檔案元資料（metadata）的支援。Mac OS X 10.4轉向了對Intel處理器的支援，因此蘋果釋出了一個測試版本的BootCamp來讓使用者安裝Mac OS X、Windows雙系統，並在Mac OS X 10.5正式整合進系統。

哪怕在Mac OS X系統執行，BootCamp也可以在時調整系統主分割槽的大小，來空出磁碟空間給Windows，因此，HFS+又需要支援動態分割槽大小調整。在Mac OS X 10.5中集成了Time Machine，它是蘋果公司所推出備份的工具程式，於2006年8月7日在蘋果計算機全球研發者大會（WWDC）中首次公開，成為當天觀眾歡呼聲最高的功能。Time Machine對於修改過的檔案會在備份盤上儲存一個新拷貝，而對於不變的內容，僅在備份盤上存一個指向先前檔案的硬連結。因此每一次快照只儲存改動的檔案，而別的檔案只儲存佔用空間很少的硬連結。但Unix一般只支援檔案的硬連結而不支援目錄的硬連結。因此HFS+在這點上走得比Unix檔案系統更遠，提供了對於目錄的硬連結支援。在Mac OS X 10.6中，HFS+甚至支援檔案系統壓縮，使得安裝後佔用比Mac OS X 10.5少得多的空間。Mac OS X 10.7提出了FileVault2，能加密整個磁碟而不是一個使用者目錄。這些功能我們在為讀者介紹每個發行版時亦會提到，但總之讀者看到，HFS+的功能隨著Mac OS X的商業需求不斷被擴充套件。“我在做了這麼多工作後回想才發現，我們為HFS+增加了那麼多新功能，”蘋果前檔案系統開發者Don Brady如是說。

由於HFS+經過後來若干年的發展，提供的功能已不遜於UFS，甚至更多更好，故至Mac OS X 10.5砍掉了安裝至UFS的支援。HFS+成為唯一正式的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分配了10GB的檔案給這個資料庫，並且在檔案頭和檔案尾寫上一些位元組的資料。而由於我們還沒有給這個資料庫新增新的資料，所以這10GB的檔案除了頭尾外其他位元組都為0。現代的檔案系統基本都支援稀疏檔案，也就是說，當處理這個資料庫操作時，事實上往磁碟寫入的資料只有那檔案頭和檔案尾的若干位元組。而HFS+則需要把那些0也寫上，因此會完整寫入10GB的資料，耗費長得多的時間。

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

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

正是由於上述這些原因，連我們介紹過的短視的Linus Torvalds都認為HFS+是個垃圾檔案系統。蘋果自然受不了這種侮辱，因此，幹掉HFS+勢在必行。用什麼取代HFS+呢？蘋果開始祕密研發下一代的檔案系統。

 作者王越，美國賓夕法尼亞大學計算機系研究生，中國著名TeX開發者，非著名OpenFOAM開發者。