熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Oracle >> 正文

用於Linux的日志文件系統

2013-11-13 15:24:39  來源: Oracle 

  最近個月以來Linux已經鞏固了其作為服務器操作系統的地位就像集群(cluster)對於企業級的應用很重要那樣日志文件系統(journaling file system)也是同樣重要的
  
  為什麼日志文件系統很重要呢?它是怎樣工作的呢?有哪些日志文件系統可以用於Linux?
  
  日志文件系統比傳統的文件系統安全因為它用獨立的日志文件跟蹤磁盤內容的變化就像關系型數據庫(RDBMS)日志文件系統可以用事務處理的方式提交或撤消文件系統的變化
  
  Ext不能滿足要求
  盡管Linux可以支持種類繁多的文件系統但是幾乎所有的Linux發行版都用ext作為默認的文件系統Linux可以支持的文件系統有FATVFATHPFS(OS/NTFS(Windows NT)Sun的UFS等等
  
  ext的設計者主要考慮的是文件系統的效率和性能方面的問題ext在寫入文件內容的同時並沒有同時寫入文件的metadata(和文件有關的信息例如權限所有者以及創建和訪問時間)換句話說Linux先寫入文件的內容然後等到有空的時候才寫入文件的metadata如果在寫入文件內容之後但在寫入文件的metadata之前突然斷電了文件系統就會處於不一致的狀態在一個需要大量文件操作的系統中(例如像Hotmail這樣的免費的Web email)出現這種情況會導致很嚴重的後果日志文件系統可以幫助解決這個問題
  
  假定你正在更新一個目錄項(directory entry)你已經在這個巨大的目錄項的第五個文件塊(block)中改變了個文件項(file entry)當正在寫這個文件塊的時候突然間斷電了這個文件塊還沒有寫完也就是被損壞了
  
  重新啟動的時候Linux(就像其它的Unix)會運行一個叫做fsck(file system check)的程序掃描整個文件系統保證所有的文件塊都被正確地分配或使用它將找到這個被損壞的目錄項並試圖修復它但是不能夠保證fsck一定能夠修復損壞修復不了是經常的事所以當出現上面那種情況目錄項中所有的文件項可能會丟失也就造成文件的丟失
  
  如果文件系統很大fsck掃描要費很長時間在一個有數十億個文件的計算機上fsck可能要運行個小時以上在這段時間內系統是不可用的也就是導致了很長的當機時間日志文件系統可以避免這種情況
  
  文件系統是怎樣工作的?
  文件系統通過為每個文件分配文件塊的方式把數據存儲在存儲設備中這樣就要維護每一個文件的文件塊的分配信息而分配信息本身也要存在磁盤上DOS和Windows的用戶可能還記得FAT這種文件系統吧不同的文件系統用不同的方法分配和讀取文件塊
  
  有兩種常用的文件系統的分配策略塊分配(block allocation)和擴展分配(extent allocation)塊分配當文件變大的時候每一次都為這個文件分配磁盤空間而擴展分配則是當某個文件的磁盤空間不夠的時候一次性為它分配一連串連續的塊
  
  傳統的Unix文件系統使用的塊分配的機制提供了一個靈活而高效的文件塊分配策略磁盤上的文件塊根據需要分配給文件這樣可以減少存儲空間的浪費當一個文件慢慢變大的時候就會造成文件中文件塊的不連續這就導致了過多的磁盤尋道時間當讀取一個文件的時候有可能要隨機而不是連續地讀取文件塊這樣的效率很低
  
  可以通過優化文件塊的分配策略(盡可能為文件分配連續的塊)來避免文件塊的隨機分配通過使用聰明的塊分配策略可以實現塊的連續分配這樣就可以減少磁盤的尋道時間但是當整個文件系統的文件塊的分配形成碎片的時候就再也不可能連續分配了
  
  每一次當文件擴展的時候塊分配的算法就要寫入一些關於新分配的塊所在位置的信息如果每一次文件擴展的時候只增加一個塊那麼就需要很多額外的磁盤I/O用來寫入文件塊的結構信息文件塊的結構信息也就是上面說的metadatametadata總是一起同時地寫入存儲設備的這就意味著改變文件大小的操作要等到所有的metadata的操作都完成之後才能進行因此metadata的操作會顯著地降低整個文件系統的性能
  
  基於擴展(Extentbased)的分配方式
  擴展分配方式一次性為文件分配很多連續的塊當創建一個文件的時候很多文件塊同時被分配當文件擴展的時候也一次分配很多塊文件系統的metadata在文件創建的時候被寫入當文件的大小沒有超過所有已分配的文件塊的大小就不用寫入metadata(直到需要再分配文件塊的時候)
  
  這樣可以優化磁盤尋道的方式可以成組地分配塊有利於一次寫一大批數據到存儲設備中這樣就可以減少SCSI設備寫數據的時間
  
  基於擴展分配的文件系統在讀取順序文件的時候有很好的性能因為文件塊都是成組連續分配的但是如果I/O操作是隨機的基於擴展分配的文件系統的好處就非常有限了例如當我們要連續地讀取一個基於擴展分配的文件的時候我們只要讀起始塊號和文件長度就行了然後就可以連續地讀取所有的文件塊了這樣在順序讀取文件的時候讀metadata的開銷就很小反之如果隨機地讀取文件我們就要先查找每一個所需塊的塊地址然後再讀取塊的內容這樣就和塊分配方式很象了
  
  在ext文件系統中對寫性能的增強是通過盡量延遲寫的時間這樣就能一次寫一大批數據而不是每次寫一小點隨之而來的就是系統效率的提高同樣當讀的時候ext也是一次讀取一整組的塊也就是采用預讀策略這樣就能提高ext文件系統的讀性能大量減少每次讀取少量數據的I/O操作
  
  文件塊的組或塊簇(block cluster)的大小是在編譯的時候確定的怎樣設定簇的大小不是這篇文章所要介紹的內容但是可以這麼說簇的大小對文件系統的性能確實有很大的影響而且簇的大小也是文件系統設計的時候需要考慮的一個很重要的方面
  
  象Veritas這樣的擴展分配的文件系統和象ext這樣的成簇寫(writeclustering)的文件系統在默認情況下都使用字節的塊而不用k字節的塊如果extk而不是k字節的塊大概會有%的性能提升但是為了減少被浪費的空間ext文件系統的設計者建議使用k字節的塊
  
  日志文件系統是怎樣解決問題的?
  先提醒你一下這節標題可能容易導致誤解日志文件系統確實解決了上面提到的一些問題但是又帶來了新問題
  
  日志文件的設計思想是跟蹤文件系統的變化而不是文件系統的內容為了更好地解釋這個問題下面我用ext文件系統和日志文件系統舉一個例子
  
  當我們改變文件testfile的內容的時候會出現什麼情況?先假定testfile的inode有四個數據塊用來保存testfile文件的數據塊的塊號分別為(因為在之間的塊已經分配給其它文件了所以這些塊不連續)當硬盤要先找到讀兩塊在跳到再讀兩塊才能讀取整個文件假定你改變了第三塊文件系統會讀取第三塊改變它然後重新寫入第三塊這一塊還在這個位置如果你往文件中添加了一些內容就要從別的地方另外分配一些空余的塊
  
  如果在日志文件系統中情況就有所不同日志文件系統不會改變第塊的內容它會把testfile的inode的一個拷貝和新的第三塊保存到磁盤上在內存中的inode列表需要更新testfile使用新的inode所有的變化添加和改變需要被記錄到一個文件系統中被稱為日志的那部分中去每隔一段時間文件系統在檢查點(check point)回更新在磁盤上的inode並且釋放文件中用不到的那些舊塊(例如testfile文件最初的第三塊)
  
  在系統崩潰之後日志文件系統很快就能恢復它需要恢復的只是日志中記錄下來的很少的幾塊當斷電之後fsck只要用幾秒鐘的掃描時間
  
  這就是我所說的解決了一些問題!
  
  但是文件系統為得到額外的安全也是要付出代價的這就是系統開銷每一次更新和大多數的日志操作都需要寫同步這樣就需要更多的磁盤I/O操作系統管理員就面臨這樣一個問題為了有一個更安全的文件系統值不值得犧牲一部分性能?
  
  大多數系統管理員會根據實際情況作出決定沒有必要把/usr目錄放在日志文件系統上因為/usr目錄大部分是只讀的操作但是可以考慮把/var或包含email spool文件的目錄放在日志文件系統上幸運的是在Linux系統中可以根據需要混合使用這些文件系統
  
  日志文件系統還有一個問題就是更容易產生碎片因為它的文件分配方式與眾不同很容易在文件系統中到處產生碎片ext文件系統也會產生碎片但是可能不會有這麼嚴重每個月定期把文件系統備份到磁帶中然後重新恢復不僅可以解決這問題而且可以檢查備份/恢復的過程是否正確
  
  想得到一些好處總是要付出一些代價的不是嗎?
  
  可供選擇的Linux日志文件系統
  當我寫這篇文章的時候有兩個日志文件系統還在開發有三個日志文件系統可供使用
  
  SGI的xfs()日志文件系統和Veritas()的文件系統和卷管理(volume manager)這兩個文件系統在五個月前就發布了但是現在還不能得到源代碼SGI的xfs是基於Irix(SGI的Unix)上已經實現的xfsSGI已經宣布xfs為Open Source的軟件
  
  兩個馬上就可以得到的日志文件系統是reiserfs和IBM的jfs這兩文件系統都是開放源代碼的而且很多有天賦的人在開發這兩個文件系統jfs(Journaled File System Technology for Linux)的開發者包括AIX(IBM的Unix)的jfs的主要開發者
  
  在A
From:http://tw.wingwit.com/Article/program/Oracle/201311/16650.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.