隨著文件系統的擴容
碎片整理愈發顯得重要
不久之前
我們工作的環境還是很小的
GB文件系統
或者是容量更小的文件
當廠家能夠提供的文件系統超過
TB時
文件的大小仍然局限於
GB
隨著我們即將進入
世紀第一個
年的中期
大文件系統常常達到
TB的容量
在今後幾年內
一些場合需要達到
TB到數PB的容量
當然
這要等技術變革之後方可實現
其中一個革新就是用基於對象的存儲設備(OSD) 代替SCSI標准
但要等到終端到終端的OSD產品成為主流
尚須時日
關於文件系統的碎片
以及文件系統的不斷擴容
我的看法如下
隨著文件系統容量的增大
文件系統的碎片也在增長
假如文件系統的容量持續增長
終端用戶即便尚未認識到這一問題的存在
也會感覺到系統的性能有所下降
要解決這個問題
需要了解下面若干知識
什麼文件系統碎片？
我的文件系統會出現這個現象嗎？
如果問題能夠解決
怎麼進行？
什麼是文件系統碎片？ 簡單地說
文件系統碎片是指在存儲設備中
對任何數據的任何訪問按計劃應該是順序進行的
但是實際並不是順序訪問的
這只是個粗略的定義
它涉及到文件系統內的數據存取方面的若干問題
背景 在我們目前所處的光纖通道/SCSI世界中
硬盤或者RAID LUN(Logical Unit Number 邏輯單元號)是簡單的塊設備
這就意味著LUN的第一個塊號為
最後一個塊號的數值小於
即以每塊
字節
共計
TB
注意
TB是目前所能創建的最大的SCSI LUN的極限了
該格式化硬盤扇區為
字節
幾乎所有文件系統在用於輪詢分配的LUN或者LUN組中
都采用首次適配算法來分配數據空間
首次適配意味著一旦找到文件系統中的第一個符合要求的空閒區
就把該數據放到其中
記住
文件系統同存儲設備通信
在存儲設備中
所有的分配單位都是
字節
即便尋址小於
字節或者不是
字節的整數倍的時侯
文件系統的尋址仍以
字節為單位
文件系統元數據是另外一個概念
關於元數據有三個部分需要強調
文件系統索引節點(inode)
當文件大小超過索引節點指定的那一個存儲單元容量時
分配的其它單元的位置
內在的文件系統
常稱之為超級數據塊(superblock)
在一些文件系統中
如果文件系統容量增大到一定限度
超級數據塊也可以被分割成文件碎片
提示一
關於索引結點(inode)
unix/linux系統為每個文件提供一個稱為索引節點的號碼inode
用於唯一的標志一個文件
可以將inode簡單理解成一個指針
它永遠指向本文件的具體存儲位置
系統是通過索引節點(而不是文件名)來定位每一個文件的物理存儲頭區域
提示二
關於超級數據塊（Superblock）個文件系統總是由它的superblock來定義的
所以創建文件系統的同時superblock也被創建
它包含了文件系統的一些基本參數
例如文件系統中的數據塊(data blocks)數和最大文件數等等
因為superblock包含了一些臨界數據
以便於進行災難性的恢復
所以缺省的superblock總是固定地位於文件系統所在磁盤分區的開始處
Superblock還有一個備份叫做冗余superblock
就像DOS中的文件分配表的副本
冗余superblock和缺省的superblock不一樣
它被分散地保存在磁盤分區上
對於文件碎片來說
元數據是個重要而且通常被忽視的領域
對於支持HSM（層次化存儲管理）的文件系統來說
這一個問題的確存在
因為這些文件系統中通常擁有數千萬甚至數億個文件
我的文件系統出現這個問題嗎？ 你的文件系統是否有碎片？確實有
但這問題不大
真正需要提出的不是是否有
而是是否造成後果？如果應用程序需要I／O帶寬有限
那麼你的文件系統即便有碎片
你仍有足夠的帶寬來滿足你的I/O需求
這一般指的是在架構或者工程中的峰值
此時
如果你的峰值性能基於一個完全碎片化的文件系統
並不會出現問題
經常發生的卻是人們為了往往購買了過多的帶寬來運行應用程序
其中的一個原因我認為就是對付文件碎片
如果在現在的
K RPM轉速的硬盤上順序分配數據
並且回讀時
在整個設備上進行讀的平均速度是每秒
MB
但是
如果數據並不是順序讀出來的
這個速度是多少？例如
考慮一個完全隨機讀
KB的應用程序
設備的平均尋道時間加上平均旋轉時間延遲為
秒
/ (
/ (
*
*
) +
))
塊大小 每秒
MB傳輸率 平均尋道加延遲時間
此時
每秒讀出數據僅為
個
KB
即
MB/sec的傳輸率
僅僅是順序I/O平均值的
/
當然
這是我們在系統中采用了多個
MB/sec 的通道以及大量硬盤的原因
幾乎所有的應用程序都無法滿負荷地用足多個
MB/sec 通道來讀／寫數據
但是這的確需要
因為要對付不少應用程序所產生的小容量的隨機的I/O操作
數據碎片 隨著文件系統的數據的容量增大
隨著文件的創建和刪除
信息的搜索越來越耗時
對於小文件來說
這不成問題
因為小文件通常在一個文件分配塊中也裝得下
而大文件就成了大問題
什麼是大文件
這取決於文件系統中的空間分配的大小
如果文件系統中最小的分配單位是
MB
而你的文件的平均大小為
MB
那麼我認為這是個小文件
而不是大文件
因為你需要調用分配空間子程序至多
次
另外一方面
如果分配單位是
KB
這樣調用分配空間子程序的次數就多了
那麼同樣的
M文件就是一個大文件了
每當你返回調用分配子程序
來查找空閒空間時
還會同其他進程競爭空間的分配
記住
空間分配通常采用的是首次適配算法
所以所獲得的空間取決於已經分配了空間的文件
以及其他請求空閒空間的進程
這就回到了我最初的斷言
多數應用程序並不是滿負荷地用到完全的文件系統的帶寬
同時多數架構配有足夠的硬盤和通道傳輸速度（IOPS）以便滿足多數應用程序的需要
元數據碎片 只是到最近
元數據的碎片方成為一個大問題
隨著文件系統的增大
文件系統的元數據所需要的空間也隨著加大
進而引發性能問題
為了元數據的性能
在架構上所做的大改進可以追溯到上個世紀八十年代克雷計算機公司的研究人員所做的工作
那就是把數據設備同元數據設備分開
從那時起
在大型環境中所使用的大多數文件系統能夠分隔（或者具有分隔這一選項）數據和元數據
而且多數能夠記錄操作的文件系統也能夠把日志存放到一個單獨的設備中
對於我所了解的多數文件系統
同對數據的分配一樣
對於元數據的分配也是順序進行的
如果你創建了一個文件
之後又創建了一個
你會使用順序存儲的文件索引節點
如果你刪除一個文件
該文件所對應的索引節點所對應的空間就可再次被分配出去
仍然采用首次適配算法
在不少的目錄中進行文件添加和刪除操作
如果這個工作反復進行
最終對元數據的分配就成為隨機的了
運行諸如 ls
l這樣的命令之後
即需要按照字母順序讀出文件的元數據
可能包含一個小容量的讀操作（通常為
字節）
有一個平均尋道和平均延遲事件
以及另外一個讀操作
基本上
我們僅能每秒進行
次讀
這同以前我們進行的
KB的 I／O操作毫無二致
當然
這意味著尋道和延遲時間遠比數據的傳輸時間要高
所以
這種場合中
性能將會很糟
當然
這純粹是從純理論角度分析的
因為還存在不少其他因素
例如RAID緩存
RAID 提前讀
inode提前讀
inode分配空間的大小
inode緩存等
另外一方面
存在其他影響性能的因素
例如到終端的延遲和競爭
據我所知的一個站點
其ls
l命令在客戶獲得元數據前就花費了大約
秒
這主要是為每個文件和每個目錄逐一重寫索引節點
在重寫完畢之後
ls
l命令僅僅花費了
秒
結論 諸如NTFS這樣的有碎片整理程序的文件系統
能夠對數據空間進行整理
有時也包括元數據空間的碎片的整理
注意我沒有提到元數據
而僅僅提到元數據空間
因碎片而造成的性能下降一般不是立即發生的
而是隨著時間逐漸顯露出來的
這就給診斷帶來了難度
通常
當文件系統的碎片情況很嚴重時
文件系統的性能已經處於很差的狀態
通常一些支持層次化存儲管理（HSM）的文件系統
支持傳輸和恢復文件系統元數據
當恢復元數據時
一般是以更為優化的方式進行的
但這卻很耗時
元數據碎片是一個新問題
僅僅在最近才浮出水面
要等文件系統開發商徹底解決該問題
尚需時日
文件系統在最近幾年來的增速驚人
不久之前（
）
TB的文件系統已經很大了
如今使用的是
TB的文件系統
這已經遠超出摩爾定律的曲線
重要的是要認識到數據和元數據均存在碎片問題
需要依靠工具和廠商來解決這些問題
From:http://tw.wingwit.com/Article/os/xtgl/201311/9007.html
