熱點推薦:
您现在的位置: 電腦知識網 >> 操作系統 >> Windows系統管理 >> 正文

一個常被忽視的問題:聚焦文件系統碎片

2013-11-11 21:41:50  來源: Windows系統管理 

  隨著文件系統的擴容碎片整理愈發顯得重要不久之前我們工作的環境還是很小的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
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.