最近的EMC-NetApp性能基準測試爭議讓我想到：過硬的性能件并不是唯一可能需要修正的性能基準測試種類。文件系統性能基準測試也可能會誤導。
最近的EMC-NetApp性能基準測試爭議讓我想到：過硬的性能件并不是唯一可能需要修正的性能基準測試種類。文件系統性能基準測試也可能會誤導。
過硬的性能件測試中，你可以控制時鐘速度、內存、總線、BIOS（基本輸入輸出系統）、編譯器等。但是對于文件系統來說，你可能會遇到更多的變量，因此可以控制設置的選擇也就更多。
我看到過許多將文件系統A和文件系統B進行比較的性能基準測試結果。這里我不列出廠商的姓名，但是我看到過許多廠商的聲明聲稱他們的文件系統比其他文系統要更快。我讀過一些性能基準測試比較文件，而它們經常和真實的使用情況不相符合。作為一個曾經給過硬的性能件廠商進行過性能基準測試比較的人，我知道這些性能基準測試結果更多的是一種營銷手段。如果是正式的采購，你會仔細讀這些性能基準測試規則，并盡可能的利用各種錯誤和漏洞來為你的產品增光添彩。
因此，讓我們來仔細看看一些文件系統性能基準測試。希望你能利用這些信息來讓那些進行性能基準測試比較的公司知道我們希望性能基準測試能夠反映真實世界的情況。
性能基準測試手腕和騙局
這里，我們將性能基準測試類型分為"容易的"性能基準測試和"過硬的"性能基準測試兩種。容易是指設置是容易的，測試是容易的，而結果是不那么實用的。過硬的性能基準測試是容易性能基準測試的對立面–而這也是唯一能夠得到有效的性能基準測試結果的方式。
容易的文件系統性能基準測試包括：
文件系統建立后的讀/寫性能測試：這種類型的測試中，塊大小通常被選擇為符合存儲設置設計的最佳大小。
文件系統建立后的文件建立測試：對于其中一些這種測試，文件系統元數據是預建好的，而文件是按最優的方式建立的（在一個文件目錄中按順序建立文件，或者在每個文件目錄中建立最佳數量的文件）。
文件建立測試后的文件刪除測試：為了能夠快速刪除文件，文件被按順序建立。
進行容易的文件系統性能基準測試測試基本上是出于兩個原因。廠商不用花費大量的成本和時間就可以進行測試，而它們的結果也很容易解釋給公眾、營銷人員和銷售人員。
過硬的性能基準測試是容易性能基準測試的對立面，幾乎所有的部分都要花費更長的時間，花費更多的成本，而且比較難解釋。同樣還是用這三個例子，這里我們看看如果使用過硬的性能基準測試，它們應該是什么樣子的：
穩定碎片水平下的讀/寫性能測試：這需要很長的時間，因為其過程是建立文件系統，增加和刪除文件，進行性能測試，接著增加和刪除文件，然后再進行測試。這個過程將一直持續到文件系統測試進入穩定狀態，而新的文件系統碎片不再影響測試結果為止。在我曾進行過的一些測試中，這種測試結果的性能水平可能要比容易測試的結果低99%。
使用隨機建立技術和和支離破碎的元數據區域來進行文件建立測試：幾乎沒有人曾在非最優條件下使用具有支離破碎的元數據區域的文件系統來進行文件建立測試，但是這種情況確實對性能具有很大的影響。
基于隨機建立文件及目錄條件下的文件刪除測試：文件是隨機建立的，因此其測試時間通常要比順序建立條件下的時間長。
我認為廠商之所以幾乎不愿做過硬的性能測試的另一個原因是在碎片文件系統數據或元數據上沒有一個公認的標準流程。由于在這個領域沒有標準的性能基準測試，更沒有公認的進行這類測試的方式，任何試圖進行過硬的性能測試的廠商都可能面臨對其結果的質疑，但是這種方式的測試是非常重要的。比起容易測試的結果更重要的是，在過硬的性能基準測試的觀察性能中，我所看到的文件系統性能退步可能要2倍、5倍、甚至500倍于容易性能基準測試。
一種最沒意義的文件系統測試就是將兩個具有不同運行目標的文件系統進行比較。一個例子就是在測試中運行COW（寫時復制）文件系統，并且在該文件系統讓整個文件或多個文件的大小和內存相匹配，然后與其相比較的文件系統卻并不使用所有內存來整合寫入操作，而是一種持續將數據流入磁盤的文件系統。毫無疑問，如果文件大小小于內存，那么COW文件系統的運行速度將更快。但是，如果文件大小十倍于內存，或者是在RAID（獨立磁盤冗余陣列）高速緩存情況下，而文件大小十倍于RAID高速緩存，那么猜猜看哪個文件系統更可能勝出。不會是COW文件系統，因為它現在必須消耗更多的CPU資源來尋找最老的塊，并將它們寫出，而其內存將一直滿載更多的數據。而流文件系統在這種情況下能夠更好的工作。
選擇最適合你工作情況的文件系統
最早的有關日志結構文件系統（LFS）的文章是"LFS存儲管理工具"，其作者是Mendel Rosenblum和John K.Ousterhout。該文章在1990年六月發表于在加州Anaheim召開的USENIX夏季技術討論會。
建立這種文件系統的主要原因之一是他們希望解決無磁盤Sun-3工作站的宕機問題，以及減少進行fsck（文件系統檢查及修復命令）的時間。我所看到的方式是，他們試圖通過不檢查和修復（fsck）整個文件系統來用一個軟件方式解決這個過硬的性能硬件問題（系統經常宕機）。這確實是一個好主意。之后，所有人都轉向日志結構文件系統，因為過硬的性能件出現問題后重啟和快速運行非常重要。另一個文件系統，Reiserfts，其設計是用于滿足Usenet新聞服務器上高速增加刪除文件的需求，而許多文件系統的設計是為了解決一個問題或另一個問題，因為在基于塊存儲的設備上，不可能將文件拓撲復制到設備上，并使其足夠靈活以解決數據通路中的內在延遲問題。
無論何時，當我看文件系統的時候，我會努力理解其設計目的，以及它們所想要解決的問題。如果一切符合，那么我就看它們所使用的過硬的性能件技術?，F在，文件系統有許多I/O問題，比如：我正在工作的筆記本電腦需要更多的高速緩存，我的臺式機需要更好的I/O性能來編輯視頻，可以被高速緩存或不能高速緩存的低速和高速數據庫，優化I/O以捕捉諸如高速電影片段等這樣的東西，保存歸檔等。無論廠商對其文件系統說什么，一個文件系統不可能同時在高性能下解決所有這些問題。你可能可以用一個高度可調的文件系統、一個性能專家以及通過設置來解決其中一些問題，但肯定不是所有問題。
現在市場上有一些關于文件系統性能基準測試的高調的市場宣傳語言，以我所見，沒有一個性能基準測試符合真實世界的問題。我把這些性能基準測試看成是像CPU核數和GHz主頻等這樣的指標。有許多和核以及GHz同樣重要的影響真實性能的其他因素；問題是沒有人做這些測試，而這種情況我看也不會有很快改變。在你決定選擇文件系統之前，要先理解你的要求，并且至少看一下性能基準測試環境以及文件系統在其中的表現。對于筆記本電腦來說，用COW文件系統來測試內存范圍內的性能可能是個好主意，但是對于測試100TB大小的OLTP（聯機事務處理系統）數據庫來說，就不好了。
