接續 上一篇 來繼續最後海量的測試，及結論。
原文是 One Billion Dollars! Wait… I Mean One Billion Files!!! (十億
元，不，我意思是十億個檔案)
海量的規模測試
先以2TB的SATA硬碟串成100TB的大容量儲存體，
再用ext4來格式化，
並以前篇文的測試步驟來進行，
而測試檔案以20KB的檔案十億個來進行，
以下是試驗的摘要：

mkfs來格式化檔案系統，約四小時。
塞十億個20KB的檔到系統，需約四天。
跑fsck來整理修復十億個檔，約2.5小時。
XFS仍會有問題，是關於with meta-data intensive workloads
較快的儲存體是有幫助的。特別是，btrfs利用SSD來當metadata為中介來存取較慢的儲存體裡的資料。
作者希望讀者能看一看 Hard Drive Caching with SSDs 這一文，
利用SSD來當其他儲存體的cache；
或者利用flashcache的機制，
能讓btrfs快速取用所需的檔案。

報告指出，檔案大小為0的及小檔案的速率是一致的。
從這測試中可知，現有的檔案系統可以處理十億個檔案，
只是在SATA硬碟上不會你所希望的那麼快速，
而且也真的能做fsck的動作。
(若希望更快的話，可藉由MLC為基礎的SSD)

從這測試能得知以下的情況：
當要fsck十億個檔的ext4系統(總共70TB的容量)，在操作中大約用掉10GB的記憶體。
這對現在的筆電、桌電而言是很大的資源，
但對server而言，這樣的記憶體量是很平常的。

用xfs_repair來修復大檔案系統，需要30GB的記憶體，這對server而言卻是相當大的。

報告也指出，有十億個檔的檔案系統，執行ls的命令不是個好主意。
理由是會同時用到readdir及stat的兩個系統函式，
意味著所有的metadata會被讀取兩次，
結果會造成花更多的時間來執行ls指令。
甚至他也指出，要執行詳列檔案的更多訊息的ls的動作時，
會花更多的時間才能完成ls的執行。

已有一些提議來改善ls對大檔案系統的回應，但也無法適用各種情況。
一種提議是用 lazy updates 在metadata上，
是在系統裡有metadata的摘要，
當使用者執行ls的時候，
能快速將這摘要讀取，
把結果回應給使用者。
然後，lazy意味著這摘要資料，不是絕對精確的。
可能是檔案大小不是絕對正確，
或者該檔案可能不是執行ls之前所產生的檔案。
但lazy updates是讓使用者能獲得該系統檔案狀態的概念。
當然，ls可以加上像 -accurate的參數，
叫指令使用 readdir 及 stat 去獲得檔案系統的最正確的狀態。

然而，甚至這accurate的參數，
也不見得能獲取最正確的資訊。
因為有這麼龐大數量的檔案，
當讀取最後一個檔案之時，
而曾讀到的第一個檔案的狀態可能已經改變了。
為了要獲得大檔案系統的超正確的值之時，
需要暫時凍結檔案系統，執行操作，
然後再繼續一般地使用檔案系統。
不確定有多少人願意這樣子的作法。
但問題是，ls已是一些script中的一部份。
不是最好的想法，但若有需要也是可以這樣子進行。

最後，報告指出其他的情況。
一是，做遠端備份複製，需要很長的進行過程。
因要讀取每個檔案的詳細資料，而更增加整個處理的時間。

二是，因備份要這麼久的時間，可能導致易於備份失敗，
結果讓這可能一些IO上碰到的壞軌或什麼的，
做一些重試的動作，而需要發展出檢查點、或區段的重試，
而不致要整個大系統重作。

簡而言之：
聽起來簡單、概念上也很簡單。
試驗也指出現有的檔案系統的限制。
隨著資料的大量增加，能夠大到放十億個檔案系統將會成為一種需要。

而用一百萬個的小檔做簡單的測試是沒問題。
但這些試驗看出不同檔案系統在效率上的表現。
好消息是十億個檔案可在檔案系統中仍有功能，
但需要有耐心等那完成操作的時間。

而十億個檔的試驗，在現有系統可運作，但很慢。
在不同檔案系統有不同的效率，可得知：
較快的儲體真的有助效率提升。
在十億個檔案裡做ls不是個好做法。需重新思考怎樣的ls在大檔系統能更有效率。
執行備份或遠端複製是要很長的過程。而長時間的過程易失敗，而需有檢查點或能區段重做的能力。

系列文章