centos中日志式文件系統的示例分析

這篇文章主要介紹了centos中日志式文件系統的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

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中日志式文件系統的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!