Red Hat日志檔案系統－ext3

概要：

在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強制寫操作按特定順序進行。