其實很簡單，可以參考Google的GFS以及變種HDFS、淘寶TFS以及騰訊Tencent FS的設計。這些都是處理大量小檔案的典範。
大家知道傳統的檔案系統下，每個檔案都要被建立對應的inode之類元資料，但是在海量檔案場景下，傳統FS已經無法承載如此多的元資料IO量以及如此龐大的元資料搜尋計算量了，唯一的做法就是降低元資料量，那麼勢必就要降低檔案實體的數量，所以這些檔案系統無一例外的都是用了這樣一種變通的方法，即在檔案中再建立檔案，比如一個64MB的大檔案，比如其中可以包含16384個4KB的小檔案，但是這個64MB的大檔案只佔用了1個inode，而如果存放4KB的檔案的話，就需要16384個inode了。
那麼如何定址這個大檔案中的小檔案呢？方法就是利用一個旁路資料庫來記錄每個小檔案在這個大檔案中的起始位置和長度等資訊，也就是說將傳統檔案系統的大部分元資料剝離了開來，拿到了單獨的資料庫中存放，這樣透過查詢外部資料庫先找到小檔案具體對應在哪個大檔案中的從哪開始的多長，然後直接發起對這個大檔案的對應地址段的讀寫操作即可。另外還可以建立索引以加速檔案查詢動作。
在一個海量分散式檔案系統中，元資料就像上面的思想一樣是分級的，中控節點，也就是MDS，儲存一級元資料，也就是大檔案與底層塊的對應關係，而資料節點則存放二級元資料，也就是最終的使用者檔案在這些一級大塊中的儲存位置對應關係，經過兩級定址從而讀寫資料。其實這些一級大檔案，就可以認為它們是捲了，也就是在卷管理層之上再存放檔案，這樣就降低了單一空間下的檔案總數量從而提高效能。
其實很簡單，可以參考Google的GFS以及變種HDFS、淘寶TFS以及騰訊Tencent FS的設計。這些都是處理大量小檔案的典範。
大家知道傳統的檔案系統下，每個檔案都要被建立對應的inode之類元資料，但是在海量檔案場景下，傳統FS已經無法承載如此多的元資料IO量以及如此龐大的元資料搜尋計算量了，唯一的做法就是降低元資料量，那麼勢必就要降低檔案實體的數量，所以這些檔案系統無一例外的都是用了這樣一種變通的方法，即在檔案中再建立檔案，比如一個64MB的大檔案，比如其中可以包含16384個4KB的小檔案，但是這個64MB的大檔案只佔用了1個inode，而如果存放4KB的檔案的話，就需要16384個inode了。
那麼如何定址這個大檔案中的小檔案呢？方法就是利用一個旁路資料庫來記錄每個小檔案在這個大檔案中的起始位置和長度等資訊，也就是說將傳統檔案系統的大部分元資料剝離了開來，拿到了單獨的資料庫中存放，這樣透過查詢外部資料庫先找到小檔案具體對應在哪個大檔案中的從哪開始的多長，然後直接發起對這個大檔案的對應地址段的讀寫操作即可。另外還可以建立索引以加速檔案查詢動作。
在一個海量分散式檔案系統中，元資料就像上面的思想一樣是分級的，中控節點，也就是MDS，儲存一級元資料，也就是大檔案與底層塊的對應關係，而資料節點則存放二級元資料，也就是最終的使用者檔案在這些一級大塊中的儲存位置對應關係，經過兩級定址從而讀寫資料。其實這些一級大檔案，就可以認為它們是捲了，也就是在卷管理層之上再存放檔案，這樣就降低了單一空間下的檔案總數量從而提高效能。