本文來自李明子csdn博客（http://blog.csdn.net/free1985），商業轉載請聯繫博主獲得授權，非商業轉載請註明出處！
本文成文於2010年11月，背景是筆者所在的GIS產品開發組對資源緩存文件（單文件文件櫃）的文件格式選型出現分歧。當時，一部分開發人員提出希望新版的數據引擎基於Linux夥伴算法作爲文件格式分配存儲，而包括筆者在內的另一部分開發人員堅持沿用原有的基於索引的鏈式存儲文件格式。本文即爲筆者當時用於表達自己的觀點。遺憾的是，經過項目經理決定，最終採用了基於夥伴算法的文件格式。後來，測試人員採用各種樣本對筆者基於兩種格式實現的數據引擎的存取效率進行了測試，測試結果顯示夥伴算法並無明顯優勢。以下爲討論正文。
夥伴算法作爲Linux的內存換頁算法有着成功的應用，但它的使用有着一定的侷限性。下面我將逐一結合我們的實際應用進行說明。
一、 硬件限制
夥伴算法速度較快的原因之一是硬件相關性極高。因爲內存的訪問速度和總大小的限制，致使該算法在硬件實現上與邏輯設計相差相對很小。比如在設計時的兩塊（或一個塊的內部）邏輯層上相鄰，所以訪問快。在硬件實現中，這兩個邏輯相鄰的塊實際上很可能相鄰，即便不相鄰其訪問速度也不會相差很多。而在文件系統中卻不是這樣。即便邏輯相鄰的兩塊，在硬盤中也可能分佈在不同的扇區。所以，該算法在硬盤中使用的效果是有限的。
二、 適用性
不管什麼算法或者格式關鍵在於是否使用當前系統。將一個高級算法應用於普通應用顯然是不合適的。按照原有的“索引定位塊首->讀取塊信息->讀取下一塊位置……”的方式，讀取數據的時間主要依賴於文件的大小（塊數），即“讀取一塊信息，定位到下一塊”的次數。我在本地（CPU E8400）做了測試，讀取10萬數據塊的時間爲188毫秒，如果以4K（當前默認）爲每塊大小，那麼這個數據量爲390M。我覺得已經明顯滿足了當前需求。
三、 慣例
我翻閱了一些文獻，並向其他的有過文件系統設計的工程師進行了諮詢，發現大多數主流文件（rar,zip,flv等）在數據文件處理上主要按照“有無索引”、“是否分塊”、“塊大小是否固定”進行搭配組合形成文件格式，即便是“無限級索引”這種較罕見的格式也沒有超出以上所述範疇。當然採用以上慣例除了習慣和已述原因外還有以下原因：
1、 文件轉換。當文件在有需要轉換爲其他格式時，應該提供的是《文件格式說明》，這種不能包含算法的格式說明文檔，否則即爲“違例”。即便不得不包含算法特徵的壓縮文件格式都在儘可能將數據與算法進行剝離。在我過去參與的某個項目中，因涉及多個公司同時使用一個文件格式，這點被作爲設計原則中的第一條。
2、 功能擴展。無論封裝SDK給用戶進行擴展還是我們自己進行功能擴展，如果一個文件格式不單單是數據的集合，還摻雜着複雜的數據訪問方法，那它的擴展性就非常有限，甚至在格式修改前不能擴展。
四、 分組
在內存中，申請空間的大小相對隨機。從一個字節到十幾兆都有可能，並且機率曲線趨於平滑。但在我們的系統中，各種資源文件的大小級差並不大，並且每種級別的文件數並不均勻，存在着一定的分佈規律。
五、 額外時間開銷
夥伴算法的最大缺點就是額外的時間開銷。因爲它要不斷的分割融合存儲區，對鏈表進行操作，所以對於頻繁改變（主要是刪除）的操作帶來的時間開銷是不能忽略的。
以上是我根據個人經驗和本週檢索資料後提出的一些個人觀點，盡供各位同事參考。作爲數據引擎的主要開發人員，我會根據項目組的最終決定將其實現。在實現層，以上探討過的文件格式相關操作只有代碼行數和可維護性的區別，沒有技術難度的區別。
