昨天我留了一道问题：苹果的文档系统 HFS+ 究竟烂在哪里？

当时我就相信，apple4us 一定有高手读者来解答这问题。果不其然，高手出现了，是传说中的阿西摩 GG。或许国内的同学并不熟悉这个 ID，不过，你至少有三种方式认识他。首先，是他写过一本关于苹果使用技巧的书《阿西摩的苹果学习志》，其次，是他有一个专门关于 OS X 应用的 blog OS X 拯聊室，第三，是他在 Twitter 上有账户（我们的飞猪同学就在 Twitter 上认识了这位老兄）——总之，传说中的高手来着。

更多的溢美之词留待日后吧，先来看看他的解答：

HFS 最早是在 1985 年的時候發表的，而 HFS+ 則是在 1998 年發表。

HFS 最最最令人詬病的就是這種資料結構將所有的資料全部存在在同一個資料結構中。而這種資料結構不僅會導致系統 loading 加重，也會耗損掉無謂的儲存空間，嚴重的情況下，還會導致 hugging。雖然 HFS+ 改善了一些 HFS 的一些問題，但是資料結構上的問題並沒有徹底解決。

我舉一個最簡單的例子來說好了，OSX Leopard 10.5 上的新功能 Time Machine 這個備份功能來說好了。Time Machine 的備份是依據檔案資料上得一些差異性來決定是否備份。而 HFS/HFS+ 造成最嚴重的問題就是，假設，你今天有的 10MB 的檔案，而當中你只有對這 10MB 資料當中的 1MB 做了修改。合理的作法，應該是需要在備份這 1MB 的差異性資料。然而，HFS/HFS+ 下你必須完整的重新紀錄一次 10MB。也就是說，你雖然只修改了 1MB 的資料，卻變成需要紀錄兩次 10MB 的資料。這也就是 Time Machine 效能不理想，而且浪費硬盤空間的原因。

其實 HFS/HFS+ 還有許多其他的問題存在，雖然 OSX Leopard 有在 HFS+ 上又動了一些手腳，改良了一些資料結構上的問題，但是，這種有洞補洞，亡羊補牢的作法，根本沒有辦法把 HFS/HFS+ 的問題完全根治。

我曾經在我的部落格當中寫過 Time Machine 這部份的問題。
（http://blog.osx119.com/?p=98）更值得一讀的是 Ars Technica 有發表過 Time Machine 的技術分析，也提到了 HFS/HFS+ 的詬病。（http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/14）

在 Leopard 還沒上市前，很多技術人員一直希望 Apple 能採用 ZFS 的原因。畢竟 HFS 算算也都 20 幾年的古董了，HFS+ 也都要十年了，技術上根本就太落後了！所以 Linus Torvalds 所言屬實，這點是 Apple 必須檢討的地方。

題外話，其實 OSX 現在的 GUI 框架方式，早在 NeXT OS 上就已經出現了。雖然經過了幾代的演變，改了很多東西，進化了不少，但是，那個 Finder 的結構框架，還是挺像的。有機會可以看看 NeXT OS 的 GUI 畫面，不難發現 Steve Jobs 真的是把整個 NeXT OS 帶進 Apple。

然后是 Lawrence 同学的追问：

我想 asimo 的叙述可能容易引起一些误会。按照我对 Siracusa 文章（即 asimo 给出链接的 Ars Technica 那篇）的理解，比如说你的 ~/Music 文件夹是 2G，然后你加了一首 3.9MB 的 mp3 进去，是不会导致这整个 2G 的 ~/Music 被重新拷到时光机硬盘的。这种情况是限定在单个文件（即 asimo 文中的「檔案」，英文里的 file）之上，比如你有一个 600MB 的 AIFF 或 WAVE 声音文件，然后你只是把其中两秒的音量加大了一点，时光机下一次备份时就必须把 600MB 整个拷一遍，而不是只拷那两秒。

不知这个说法正确吗？

阿西摩的补充解释：

是的，是這樣解的。

我文中所提的檔案，是指單一檔案，而非整個資料夾。