白皮書：Red Hat日誌檔案系統－ext3(轉)

白皮書：Red Hat日誌檔案系統－ext3(轉)[@more@]

Copyright © 2001 by Red Hat

翻譯：劉啟文

david.liu@dynasoft.com.cn

Copyright © 2001 by Dynasoft

概要... 1

ext3的優點... 2

可用性... 2

資料完整性... 2

速度... 2

易於遷移... 3

為什麼使用ext3？... 4

為什麼要信任ext3？... 5

效能除錯建議... 6

調整電梯（elevator）演算法設定... 6

選擇日誌模式... 7

速度... 7

資料完整性... 7

概要

在Red Hat Linux 7.2中，Red Hat首次支援日誌檔案系統ext3。ext3檔案系統是對穩定的ext2檔案系統的改進，有幾項優點。本文概述這些優點，解釋Red Hat公司對ext3進行了何種測試，略述效能除錯（為高階使用者）。

有數種基於Linux的日誌檔案系統正在開發之中。本文不言及這些日誌檔案系統，也不準備與這些日誌檔案系統進行比較。

ext3的優點

為什麼你需要從ext2遷移到ext3呢？以下有四個主要原因：可用性、資料完整性、速度、易於遷移。

可用性

在非正常當機後（停電、系統崩潰），只有在透過e2fsck進行一致性校驗後，ext2檔案系統才能被裝載使用。執行e2fsck的時間主要取決於 ext2檔案系統的大小。校驗稍大一些的檔案系統（幾十GB）需要很長時間。如果檔案系統上的檔案數量多，校驗的時間則更長。校驗幾百個GB的檔案系統可能需要一個小時或更長。這極大地限制了可用性。

相比之下，除非發生硬體故障，即使非正常關機，ext3也不需要檔案系統校驗。這是因為資料是以檔案系統始終保持一致方式寫入磁碟的。在非正常關機後，恢復ext3檔案系統的時間不依賴於檔案系統的大小或檔案數量，而依賴於維護一致性所需“日誌”的大小。使用預設日誌設定，恢復時間僅需一秒（依賴於硬體速度）。

資料完整性

使用ext3檔案系統，在非正常關機時，資料完整效能得到可靠的保障。你可以選擇資料保護的型別和級別。你可以選擇保證檔案系統一致，但是允許檔案系統上的資料在非正常關機時受損；這是可以在某些狀況下提高一些速度（但非所有狀況）。你也可以選擇保持資料的可靠性與檔案系統一致；這意味著在當機後，你不會在新近寫入的檔案中看到任何資料垃圾。這個保持資料的可靠性與檔案系統一致的安全的選擇是預設設定。

速度

儘管ext3寫入資料的次數多於ext2，但是ext3常常快於ext2（高資料流）。這是因為ext3的日誌功能最佳化硬碟磁頭的轉動。你可以從3種日誌模式中選擇1種來最佳化速度，有選擇地犧牲一些資料完整性。

第一種模式，data=writeback，有限地保證資料完整，允許舊資料在當機後存在於檔案當中。這種模式可以在某些情況下提高速度。（在多數日誌檔案系統中，這種模式是預設設定。這種模式為ext2檔案系統提供有限的資料完整性，更多的是為了避免系統啟動時的長時間的檔案系統校驗）

第二種模式，data=orderd（預設模式），保持資料的可靠性與檔案系統一致；這意味著在當機後，你不會在新近寫入的檔案中看到任何垃圾資料。

第三種模式，data=journal，需要大一些的日誌以保證在多數情況下獲得適中的速度。在當機後需要恢復的時間也長一些。但是在某些資料庫操作時速度會快一些。

在通常情況下，建議使用預設模式。如果需要改變模式，請在/etc/fstab檔案中，為相應的檔案系統加上data=模式的選項。詳情可參看mount命令的man page線上手冊（執行man mount）。

易於遷移

你可以不重新格式化硬碟，並且很方便的從ext2遷移至ext3而享受可靠的日誌檔案系統的好處。對，不需要做長時間的、枯燥的、有可能失誤的“備份－重新格式化－恢復”操作，就可以體驗ext3的優點。有兩種遷移的方法：

· 如果你升級你的系統，Red Hat Linux安裝程式會協助遷移。需要你做的工作 就是為每一個檔案系統按一下選擇按鈕。

· 使用tune2fs程式可以為現存的ext2檔案系統增加日誌功能。如果檔案系統在轉換的過程已經被裝載了(mount)，那麼在root目錄下會出現檔案”.journal”；如果檔案系統沒有被裝載，那麼檔案系統中不會出現該檔案。轉換檔案系統，只需要執行tune2fs –j /dev/hda1(或者你要轉換的檔案系統所在的任何裝置名稱)，同時把檔案/etc/fstab中的ext2修改為ext3。如果你要轉換自己的根檔案系統，你必須使用initrd引導啟動。參照mkinitrd的手冊描述執行程式，同時確認自己的LILO或GRUB配置中裝載了initrd（如果沒有成功，系統仍然能啟動，但是根檔案系統會以ext2形式裝載，而不是ext3，你可以使用命令cat /proc/mounts 來確認這一點。）詳情可參看tune2fs命令的man page線上手冊（執行man tune2fs）。

為什麼使用ext3？

為什麼Red Hat選擇ext3作為我們第一個正式支援的日誌檔案系統？這是因為ext3具有以下優點。注意這些優點每一個都不是ext3所獨有的（其它的日誌檔案系統同樣具有以下的某些優點），但是隻有ext3同時具有所有的這些優點。

· ext3全面相容ext2，允許使用者在增加日誌功能時，保留現存的檔案系統。任何想要去除檔案系統的日誌功能的使用者也不需要做很多工作（我們沒期望很多人這麼做）。而且，只要安裝了最新版的e2fsprogs程式（例如Red Hat Linux 7.2中自帶的），一個ext3檔案系統不需要去掉日誌功能，也能以ext2形式裝載。

· ext3從ext2不斷增強和改進自身功能的歷史中獲益，並且以後還將吸收ext2的優秀特性。也就是說ext3繼承了ext2許多已有的優點，同時 ext2新增加的一些特性，也會很容易的轉移到ext3中。例如當擴充套件屬性或者Htree增加到ext2中時，把這些特性加到ext3中也是很容易的（擴充套件屬性實現訪問控制列表，Htree可以提高目錄操作的速度和改進大目錄的可伸縮性）。

· ext3和ext2一樣是由來自多家廠商的開發人員聯合開發的，它的開發不依賴於任何個人或組織。

· ext3提供並使用了一個通用日誌層（jbd），該層可以在其它環境中使用。Ext3不但能在檔案系統中使用日誌功能，而且能夠應用到其它裝置中，例如目前Linux開始支援的NVRAM裝置，ext3就能夠支援。

· ext3有多種日誌模式。它可以記錄所有的檔案資料和（metadata）後設資料（data=journal），也可以只記錄後設資料（data= ordered或data=writeback）。當你不記錄檔案資料時，你可以選擇在記錄後設資料前修改檔案系統資料（data=ordered；這樣所有的後設資料記錄都指向了有效資料），或不特殊地處理檔案資料（data=writeback；檔案系統保持一致性，但是非正常關機後，檔案中會有舊資料存在）。這樣，管理員可以在速度和檔案資料一致性兩方面權衡利弊，並且可以為某些特殊的應用調整速度。

· ext3有很強的平臺相容性，它可以在little-endian和big-endian系統上，支援32和64位體系結構，。任何能夠訪問ext2檔案系統的作業系統，都能訪問ext3檔案系統，目前包括各種Unix版本及其變種，BeOS，Windows。

· ext3不要求核心做大的修改，也不需要增加新的系統呼叫，因此目前沒有什麼難題能夠阻止Linux Torvalds把ext3加入他正式的Linux核心版本中。Ext3已經整合到了Alan Cox的 –ac核心中，很快就會進入到Linus的正式核心中。

· 當由於軟體或硬體錯誤導致檔案系統崩潰時，檔案修復程式e2fsck在修復資料方面有很好的成功記錄。ext3使用了和e2fsck相同的程式碼來修復崩潰的檔案系統，因此在出現資料崩潰錯誤時，ext3和ext2同樣具有防止資料丟失的優點。

我們要再次宣告這些優點中的每一點都不是ext3所獨有的。它們中的大部分是別的檔案系統也有的。我們不過是宣告這些所有的優點真的是隻有ext3才全具備。我們是根據使用者的要求，來決定我們目前應該支援哪些特性。根據我們的測試，ext3是目前最能滿足我們使用者需要的。我們將繼續評估其它的檔案系統，以便於在以後的Red Hat Linux版本中加入這些檔案系統。

為什麼要信任ext3？

Red Hat為了確保ext3能夠安全地處理使用者資料，做了以下測試：

· 我們在各種配置下進行了大量的壓力測試。這包括在各種硬體和檔案系統配置上，進行數千小時的“專項”負載測試，以及許多用例（use case）測試。

· 我們在多種條件下觀測ext3，包括在某一點上記憶體分配錯誤的情況。每次程式碼更新，我們都反覆地強制性地製造錯誤來測試在這些條件下檔案系統的一致性。

· 我們測試出ext3和虛擬記憶體（VM）子系統之間的互動效能較差，因而進行了改進。日誌檔案系統對VM子系統有更大的壓力，並且我們在測試的過程中發現並修改了幾個ext3和VM子系統中的錯誤。經過了數千個小時的這種測試，我們對ext3檔案系統充滿了信心。

· 從2.2核心系列一直到現在的2.4核心系統，我們對ext3進行了一年多的β測試。甚至在正式的β測試以前，ext3已經被放在產品中，在一些環境中使用了。ext3應用在一些訪問量很大的伺服器上超過了兩年，例如rpmfind.net伺服器。

· 為了處理潛在的硬體故障引起的崩潰，我們已經安排允許使用者在“當機”後選擇是否檢測檔案系統的一致性，即使檔案系統被標記為“clean”。這是因為硬體故障和大部分的電力故障，幾乎能在磁碟的任何地方產生“垃圾”資料。按下重起按鈕可能不會產生這類問題，但是現實中由雷擊或電壓鉅變引起的電力故障，是會破壞正在寫入磁碟的資料的。IDE磁碟比SCSI磁碟更容易產生這類問題，部分原因是因為IDE磁碟通常使用鬆散快取（looser cancheing） 演算法。

·這種特性是使用檔案/.autofsk來實現的，如果根使用者在正常情況下刪除了這個檔案，則在引導時系統可以提供選擇是否檢查檔案系統的一致性。如果 /.autofsk不存在了並且使用者選擇對檔案系統進行強制檢查，那麼這種情況和存在檔案/forcefsck的效果是一樣的。

效能除錯建議

調整電梯（elevator）演算法設定

ext3檔案系統和ext2檔案系統有一些不同，這種不同表現在多方面。高階使用者可以調整檔案系統和I/O系統引數來改進效能。這裡主要介紹效能除錯的一些基本方法。當然，所有的效能除錯都需要針對特定的應用程式；這裡沒有適合所有狀況的效能除錯方法。但是，我們會盡力提供一些具有普遍意義的有用資訊。

Linux 的大多數塊裝置驅動程式都使用了“電梯式（elevator）”演算法來排程塊I/O操作。我們可以使用程式/sbin/elvtune調整吞吐量（throughput）和延遲時間（latency）的值，來達到最佳效果。對於給定的負載，ext3要達到和ext2檔案系統同樣的效果，需要提供給 /sbin/elvtune更小的延遲時間數值。

在某些情況下，希望犧牲延遲時間來換取最大吞吐量的企圖，會導致吞吐量下降和延遲時間的增加（在這種情況下，/sbin/elvtune使用大的讀延遲時間(-r)和寫延遲時間(-w)）。這種結果主要是由於以下原因：

· 在ext2檔案系統中，每30秒排程一次寫操作；而ext3檔案系統每5秒就排程一次寫操作。這樣做是為了防止日誌操作對系統吞吐量產生明顯的影響，同時也保持磁碟上資料的時效性。

· 因為ext3檔案系統記錄所有後設資料的變化情況，所以atime（檔案最後訪問時間）的變化情況對檔案系統的影響更大了。如果想禁止更新atime，你可以使用noatime引數來裝載（mount）檔案系統。雖然，atime不是後設資料更新的唯一來源，但是對很多系統，尤其是那些帶有大量可訪問檔案，同時又被大量訪問的伺服器來說，後設資料更新大多數都是由於atime更新。在這些系統中，關閉atime更新可以明顯的降低延遲時間和提高吞吐量。

為了除錯我們的預設檔案系統ext3，Red Hat已經把預設的讀和寫延遲時間降低了一半（從8192讀和16384寫降到4096讀和8192寫）。我們希望在普通的應用中，你可以不需要改變這些數值。在我們的測試中，我們所提供的預設數值已經表現出很好的效果。但是，為了適應特殊的應用程式，我們建議你基於自己的應用使用多個數值來測試系統效能。一般情況下，我們建議你把讀延遲時間（-r）設定為寫延遲時間（-w）的一半。

例如，你可以執行命令：/sbin/elvtune –r 1024 –w 2048 /dev/sdd 來改變裝置/dev/sdd（包括/dev/sdd上的所有分割槽）的電梯演算法設定。對一個分割槽的電梯演算法設定的改變將會影響該分割槽所在的裝置，因為一個裝置上的所有分割槽共享相同的電梯演算法（elevator）設定引數。

一旦你發現所設定的延遲時間和吞吐量引數，最適合自己的應用程式集，你可以把對程式/sbin/elvtune的呼叫命令加到檔案/etc/rc.d/rc.local指令碼的末尾，這樣系統在每次啟動時都會自動設定這些引數。

選擇日誌模式

速度

在一些典型的情況下，使用選項data=writeback可以顯著地提高速度，但是同時會降低對資料一致性的保護。在這些情況下，資料一致性的保護基本上與ext2檔案系統相同，不同的是在正常操作時，系統不斷地維護檔案系統的完整性（這是其它日誌檔案系統使用的日誌模式）。這包括頻繁的共享寫操作，還包括頻繁地建立和刪除大量的小檔案，例如傳送大量的小電子郵件資訊。如果你從ext2切換到ext3，發現應用程式效能大幅度下降，選項data= writeback可能會對你提高效能有幫助。即使你沒有獲得昂貴的資料一致性保護措施，你仍然可以享受ext3的好處（檔案系統總是保持一致）。

Red Hat還在做工作，以提高ext3某些方面的效能，所以ext3的某些方面效能在將來可以獲得改善。這也意味著即使你現在選擇了data= writeback，你也需要以data=journal的預設值重新測試將來的版本，來確定新版本的改變是否與自己的工作有關。

資料完整性

在大多數情況下，使用者都是在檔案的末尾寫入資料。僅僅在某些情況下（例如資料庫），使用者在現存檔案的中間寫入資料。甚至覆蓋現存檔案的操作，是透過先截斷該檔案，然後再從檔案末尾寫入資料來實現的。

在data=ordered模式中，如果正在寫檔案時系統崩潰，那麼資料塊可能被部分改寫，但是寫入過程並沒有完成，所以系統存在不屬於任何檔案的不完整資料塊。

在data=ordered模式中，崩潰後殘存無序資料塊的唯一情況是在崩潰過程中一個程式正在重寫某個檔案。在這種情況下，無法絕對保證寫入順序，除非該程式使用了fsync()和O_SYNC強制寫操作按特定順序進行。