深入探究CentOS中的日誌檔案系統ext3

大綱

1、日誌式檔案系統

2、ext3的優點

3、ext3的三種日誌模式

4、選擇日誌模式

1、日誌式檔案系統

通常在系統運作中寫入檔案內容的同時，並沒有寫入檔案的元資料（如權限、擁有者及建立和存取時間），如果在寫入檔案內容之後與寫入檔案元資料之前的時間差裡，系統非正常關閉，處於寫入過程中的檔案系統會非正常卸載，那麼檔案系統就會處於不一致的狀態。當重新啟動時，Linux會執行fsck程序，掃描整個檔案系統，確保所有的檔案區塊都被正確地指派或使用，找到被損壞的目錄項目並試圖修復它。但是，fsck不保證一定能夠修復損壞。當這種情況發生時，檔案中不一致的元資料會填滿已遺失檔案的空間，目錄項目中的檔案項目可能會遺失，也造成檔案的遺失。 

為了盡量減少檔案系統的不一致性，縮短作業系統的啟動時間，檔案系統需追蹤造成系統改變的記錄，這些記錄存放在與檔案系統相分離的地方，通常我們叫「日誌」。一旦這些日誌記錄被安全地寫入，日誌檔案系統就可以應用它們清除引起系統改變的記錄，並將它們組成一個引起檔案系統改變的集，將它們放在資料庫的事務處理中，保持在狀態下有效資料的正常運行，不會與整個系統的效能發生衝突。當任何系統發生崩潰或需要重新啟動時，資料會遵從日誌檔案中的資訊記錄進行復原。由於日誌檔案中有定期的檢查點，通常非常整齊。文件系統的設計主要考慮效率和性能方面的問題。

Linux可以支援許多日誌檔案系統，包括FAT、VFAT、HPFS（OS/2）、NTFS（Windows NT）、UFS、XFS、JFS、ReiserFS、ext2、ext3等。

2、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）。

3、ext3的三種日誌模式

ext3提供多種日誌模式，即無論改變檔案系統的元數據，或是改變檔案系統的資料（包括檔案本身的變更），ext3 檔案系統均可支持，以下是在/etc/fstab檔案引導時啟動的三種不同日誌模式：

data=journal日誌模式 

日誌中記錄包括所有改變檔案系統的資料和元資料。它是三種ext3日誌模式中最慢的，但它將發生錯誤的可能性降至最小。使用「data=journal」模式要求ext3將每個變更寫入檔案系統2次、寫入日誌1次，這將降低檔案系統的總效能。所有新資料首先被寫入日誌，然後才被定位。意外發生過後，日誌可以重播，將資料與元資料帶回一致狀態。由於記錄了在ext3中元資料和資料更新情況，當一個系統重新啟動的時候，這些日誌將會起作用。

data=ordered日誌模式 （預設）

僅記錄改變檔案系統的元數據，且溢出檔案資料要補充到磁碟中。這是預設的ext3日誌模式。這種模式降低了在寫入檔案系統和寫入日誌之間的冗餘，因此速度較快，雖然檔案資料的變化情況並不被記錄在日誌中，但它們必須做，而且由ext3的daemon程序在與之相關的檔案系統元資料變更前執行，即在記錄元資料前要修改檔案系統數據，這將稍微降低系統的效能（速度），然而可確保檔案系統中的檔案資料與對應檔案系統的元資料同步。

data=writeback日誌模​​式 

僅記錄改變檔案系統的元資料，但根據標準檔案系統，寫入程式仍要將檔案資料的變更記錄在磁碟上，以保持檔案系統一致性。這是速度最快的ext3日誌模式。因為它只記錄元資料的變化，而不需等待與檔案資料相關的更新如檔案大小、目錄資訊等情況，對檔案資料的更新與記錄元資料變化可以不同步，即ext3是支援異步的日誌。缺陷是當系統關閉時，更新的資料因不能被寫入磁碟而出現矛盾，這一點目前尚不能很好解決。

不同日誌模式間有差別，但設定的方法一樣方便。可以使用ext3檔案系統指定日誌模式，由/etc/fstab啟動時完成。例如，選擇data=writeback日誌模​​式，可以做以下設定：

/dev/hda5 /opt ext3 data=writeback 1 0

在一般情況下，data=ordered日誌模式是ext3檔案系統的預設模式。

要指定日誌方式，可以使用下列方式：

1 在/etc/fstab的選項欄位中加入適當的字串例如 data=journal

# /dev/sda3 /var ext3 defaults,data=writeback 1 2

2 在呼叫 mount 時直接指定 -o data=journal 命令列選項。

# mount -o data=journal /dev/sdb1 /mnt

如果我們想要查看某一個檔案系統的日誌方式該怎麼查詢，這裡可以透過dmesg 指令：

# dmesg | grep -B 1 "mounted filesystem" 

kjournald starting.  Commit interval 5 seconds

EXT3-fs: mounted filesystem with ordered data mode.

--

EXT3 FS on sda1, internal journal

EXT3-fs: mounted filesystem with ordered data mode.

--

EXT3 FS on sdb1, internal journal

EXT3-fs: mounted filesystem with journal data mode.

--

EXT3 FS on sdb1, internal journal

EXT3-fs: mounted filesystem with writeback data mode.

4、选择日志模式

速度

在一些典型的情况下，使用选项data=writeback可以显著地提高速度，但是同时会降低对数据一致性的保护。在这些情况下，数据一致性的保护基本上与ext2文件系统相同，不同的是在正常操作时，系统不断地维护文件系统的完整性（这是其它日志文件系统使用的日志模式）。这包括频繁的共享写操作，还包括频繁地创建和删除大量的小文件，例如发送大量的小电子邮件信息。如果你从ext2切换到ext3，发现应用程序性能大幅度下降，选项data=writeback可能会对你提高性能有帮助。即使你没有获得昂贵的数据一致性保护措施，你仍然可以享受ext3的好处（文件系统总是保持一致）。Red Hat还在做工作，以提高ext3某些方面的性能，所以ext3的某些方面性能在将来可以获得改善。这也意味着即使你现在选择了data=writeback，你也需要以data=journal的缺省值重新测试将来的版本，来确定新版本的改变是否与自己的工作有关。

数据完整性

在大多数情况下，用户都是在文件的末尾写入数据。仅仅在某些情况下（例如数据库），用户在现存文件的中间写入数据。甚至覆盖现存文件的操作，是通过先截断该文件，然后再从文件末尾写入数据来实现的。在data=ordered模式中，如果正在写文件时系统崩溃，那么数据块可能被部分改写，但是写入过程并没有完成，所以系统存在不属于任何文件的不完整数据块。在data=ordered模式中，崩溃后残存无序数据块的唯一情况是在崩溃过程中一个程序正在重写某个文件。在这种情况下，无法绝对保证写入顺序，除非该程序使用了fsync()和O_SYNC强制写操作按特定顺序进行。

ext3文件系统还涉及到如何cache中的数据刷到硬盘上。它是通过kupdate进程来实现定期刷的，默认是5秒检查一次，将超过30秒的脏数据刷到硬盘。

在as 3.0中可以通过修改/proc/sys/vm/bdflush来达到目的。而在as 4.0中可以通过修改/proc/sys/vm/dirty_writeback_centisecs和/proc/sys/vm/dirty_expire_centisecs来达到目的。

由于默认是ordered模式，在这种模式下面，如果一个IO先写数据文件，然后再写日志文件。假如说在写完数据文件之后，写日志文件之前时，系统发生crashed，则这部分数据将会丢失，这在数据库是绝对不允许的，不管是Oracle还是MySQL。所以对数据库的写来说，每一次写操作都会先写到pagecache中，然后通知kernelthread 将这个buffers刷到硬盘，然后再将元数据写日志，最后才返回写成功的操作。这样对数据库来说写操作是明显不如写祼设备快。

所以说在采用Ext3跑数据库的情况下，将日志模式设为journal模式，性能反而应该会有所提升(没有测试过，理论上分析应该 是这样)。 因为在journal模式下数据库一个写操作，先是直接将数据和文件系统的变化写到日志中(绕开cache直接写，性能较好)，然后将数据写到cache 中，接着由kupdate进程将数据刷新到硬盘上。 相比之下，对DB来讲，它的性能应该比前面一种要快。

另外这里还提一下MySQL中的sync_binlog这个参数。如果将这个参数设为1，也就是说每次写binlog文件将同时刷到硬盘上面去，就 像Oracle的写IO一样。如果将这个参数关闭，则它交给OS来管理，也就是每5秒检查一次，发现有30秒以前的老数据则刷到硬盘上。 innodb_flush_log_at_trx_commit参数来也涉及到刷硬盘的问题。

ext3作为ext2的增强版，和ext2使用的superblock、inode、group descriptor等数据结构几乎一模一样，所以ext3前向兼容ext2。在不用备份ext2文件系统数据的情况下，可以用：

1

# tune2fs –j/dev/sd1

在不用卸载分区的状态下直接将ext2文件系统转换成ext3文件系统。

假如说，我们在编辑文件时，突然停电了、或系统被锁定被迫得重启，会出现什么后果？轻则文件丢失部分内容，重则整个文件内容混乱，更有甚者文件系统直接崩溃。这将会是多么可怕的一件事儿。在linux正常关机时我们都会看到一条卸载文件系统的打印信息，而非正常关机会导致文件系统出现不一致，在系统重新启动阶段挂文件系统时会发现这种不一致，然后它便会尝试去修复它。不幸的是，随着存储设备容量的增大，这种修复工作所花费的时间越来越无法让人容忍。

Ext3的最大特性就是在ext2的基础上增加了日志功能，所以ext3文件系统也经常被人们称之为日志文件系统，但日志文件系统觉不仅仅只有ext3，还有诸如JFS、reiserFS和XFS，以及我们在Windows上经常见到的NTFS等。

Ext3的日志特性主要是依靠其下层一个名为“日志块设备层”的中间设备来完成，叫做JBD(Journaling Block Device layer 简称JBD)。JBD并不是文件系统规范的一部分，它和ext3文件系统的规范是没有任何的关系的，而JBD正是文件系统事务处理功能的实现基础。简而言之，JBD 被设计成在任何块设备上实现日志的特殊目的(越说越抽象，事务是个啥玩意儿啊⊙﹏⊙….)

关于事务，有过数据库开发经验或者做数据运维的同学肯定不会陌生。这里咱不就结概念，也不拘泥学术定义，大家只要知道事务的主要作用就是为了保证操作的原子性。这句话如何理解？比如说，在金融系统中，要从账户A转账X元到账户B。这一业务必须要确保从A账户成功划出了X元，然后往B账户成功增加了X元。只有这两个操作同时成功才能任务是转账成功，任何一个操作失败该业务必须终止。假如从A账户转出X元成功，当往B账户写入时出现了错误，那么从A账户转出的X元必须被退还到A账户。更极端的情况是，此时A账户所在的数据由于种种原因又崩溃了，那么数据库的事务机制必须保证A账户的X元不会丢失。这就是数据库业务操作的原子性。在日志文件系统中这种对文件数据操作的原子性是由JBD来提供保证，Ext3 通过“钩子（hooking in）”JBD的API 来实现其日志记录的功能。JBD层本身虽然代码不多，但却是个相当复杂的软件部分，这里我们先不鸟它，以后有机会再陪它玩玩儿。

日志文件系统当然要记录日志，而日志也需要占存储空间。所以，日志文件系统就是在存储介质上开辟一个块特殊的区域专门用于存储日志信息：

我们利用一幅图来简单描述ext3底层的layout：

以上是深入探究CentOS中的日誌檔案系統ext3的詳細內容。更多資訊請關注PHP中文網其他相關文章！