白皮書：Red Hat日志文件系統－ext3

　　Copyright © 2001 by Red Hat 翻譯：劉啟文 [email protected] 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強制寫操作按特定順序進行。