轉自http://blog.csdn.net/yinwenjie/article/details/52430409
================================
（接上文《架構設計：系統存儲（3）——塊存儲方案（3）》）
6-2、Ext2和Ext3的區別
在上文6-1小節中介紹的Ext文件系統結構主要適用於Ext2和Ext3文件系統，這兩個版本的Ext文件系統在數據組織結構上基本上沒有什麼變化。Ext3文件系統相對於Ext2文件系統所做的主要優化在數據寫入策略上。
6-2-1、Ext2寫入過程概要
Linux操作系統爲了加快I/O操作過程，當有文件需要寫入文件系統時Linux操作系統並不會立刻將文件數據實際寫入data block，而是存儲到一個內存區塊中。如果您通過top命令或者Free命令，就可以看到這個名叫cache memory的內存區塊。
[root@lab-backup ~]# free
total used free shared buffers cached
Mem: 3805272 3662628 142644 508 1758376 1491128
-/+ buffers/cache: 413124 3392148
Swap: 3948540 0 3948540無論是Ext2文件系統還是Ext3文件系統又或者是Ext4文件系統，寫入cache memory區塊的這個過程是不會改變的。以上示例效果中還有一個叫做buffers memory的內存區塊，這個區塊緩存了文件系統的部分Inode信息，這樣保證了操作系統不會隨時到文件系統上尋找Inode——優化文件系統的讀性能。cache memory區塊和buffers memory區塊由操作系統自行管理，它們只會使用當前沒有被應用程序佔用的空閒內存。當應用程序請求新的內存區塊且空閒內存不夠時，操作系統會釋放部分cache memory區塊或者buffers memory區塊。後文我們講解Linux下的Page Cache技術時，還會對這部分只是進行詳細講解。當cache memory區塊寫滿或者到達一個等待時間後，操作系統就會正式開始向文件系統寫數據了。
在Ext2文件系統中，完成文件寫入的過程可以簡要的進行如下描述：首先文件系統會在收到文件寫入請求後根據算法尋找一個還沒有使用的Inode，這個算法過程根據不同文件系統小版本和Linux內核版本的不同而有所變化，但尋找原則都是一樣的，即儘可能爲文件尋找連續的inode和data block。上文已經提到Ext文件系統中，每一個block group都有Block bitmap區域和Inode bitmap區域分別用於記錄block group中的block和Inode的使用情況。在尋找Inode的這個步驟中，block group的Block bitmap、Inode bitmap區域還不會被寫入任何變化，block group的Group description table區域也不會被寫入任何變化。
接下來Ext2文件系統就要向硬件層正式寫入數據了，這個步驟還包括建立Inode和data block的關聯信息。最後當文件系統相對空閒的情況下，文件系統纔會更新block group中的Block bitmap、Inode bitmap和Group description table區域。正常情況下這種操作過程並沒有太大的問題，因爲文件系統隨時都清楚哪些Block bitmap、Inode bitmap被真正使用了，哪些Block bitmap、Inode bitmap是被使用但還沒有來得及更改狀態。當文件系統正常關閉時Ext2文件系統會設置一個校驗標記Valid bit=1，表示本次文件系統的操作正常結束。
但是如果當文件系統因爲各種原因異常關閉時（例如斷電）這個標記的值就爲0，那麼問題就來了。因爲哪些已經被使用但還沒有來得及被標示的Block bitmap、Inode bitmap區域，和真實的使用情況就存在誤差了。雖然操作系統下次啓動時會對整個文件系統進行掃描試圖恢復操作（主要目的是恢復Block bitmap、Inode bitmap和真實事情情況的一致性），但是操作系統並不保證一致性被全部恢復。這樣看來Ext2文件系統的寫入過程至少存在一下幾個問題：
由於data block塊的寫入操作和Block bitmap、Inode bitmap區域的更新過程是分開進行的，所以當系統異常關閉時Ext2文件系統並不能保證Block bitmap、Inode bitmap的狀態和真實的block使用情況完全一致。所以纔會有系統重啓時試圖恢復磁盤一致性的修復操作。
Ext2文件系統對於大文件的讀寫性能並不好，這是因爲當文件特別大時，Ext2文件系統會啓用三級間接指針和四級間接指針建立Inode和data block的聯繫。雖然當data block size爲4KB時單個文件的大小可達4TB，但是因爲存儲大文件時會啓用二級、三級甚至四級間接指針，這大大增加了文件系統上的索引查找時間。所以這種多級索引的思路除了可以增加單個文件容量外，對提升大文件的讀寫性能實際上並沒有太多幫助。
另外Ext2文件系統在向data block寫入文件數據時，將以data block size（默認爲4KB）爲單位依次向硬件層提交數據，這就是爲什麼在其它設置不變的情況下，如果將Ext2文件系統的data block size格式化爲8KB，會增加一定的磁盤讀寫性能的原因。
6-2-2、Ext3日誌模式
以上小節中提到的Ext2文件系統的明顯問題中，最嚴重的應該還是文件系統異常情況下Block bitmap、Inode bitmap可能出現的一致性問題。所以Ext3文件系統在基本保持Ext2文件系統組織結構的前提下，使用索引日誌的思路來解決Ext2文件系統上的數據一致性問題。
Ext3文件系統又被稱爲日誌文件系統，它在Ext2文件系統的基礎上做的主要改動就是，在正式寫入data block數據並建立Inode索引前，通過在磁盤上的某塊固定位置寫入一段日誌數據的方式建立這兩個操作過程的關係，並根據後續操作進行日誌數據的保留/刪除，以達到保持操作一致性的目的。這樣一來，即使文件系統上一次異常關閉，當文件系統再次啓動時也不需要再進行整個文件系統Inode和data block掃描了，只需要重新加載日誌數據文件系統就可以知道上一次異常關閉時還有哪些Block bitmap、Inode bitmap沒有處理完。
Ext3文件系統支持三種日誌模式，他們在數據一致性和I/O性能上有所區別：
journal日誌模式
在這種模式下，當文件系統正式開始進行磁盤操作前會在磁盤的上專門的日誌區域創建這個文件的副本，包括這個文件的Inode和data block完整信息，副本創建完成後纔會按照正常的寫入過程進行文件寫入。當寫入操作正常完成後，文件系統會刪除日誌區域的文件副本。這樣一來當文件系統發生異常並重啓後，e2fsck檢測程序會掃描日誌區域中的副本：如果發現文件副本本身就不完整，則會丟棄這部分副本。如果發現文件副本是完整的，則會繼續完成正式文件的寫入過程，最後刪除文件副本。很顯然journal日誌模式會增加單個文件的磁盤操作次數，所以journal日誌模式是三種日誌模式中速度最慢的一種。但是journal日誌模式卻可以做到最完整的數據一致性要求。
ordered日誌模式
ordered日誌模式是Ext3/Ext4文件系統默認的日誌模式。這種模式比 journal日誌模式快了許多，因爲ordered日誌模式下Ext文件系統的日誌區域並沒有真正記錄文件的真實數據，不會發生一個文件的多次讀寫過程。當文件系統爲新文件確定了Inode和block區域後，這些Inode、Block bitmap、Inode bitmap等索引信息將會首先保存到文件系統的日誌區域，並形成一個事務單位。當文件數據被完整寫入磁盤對應的block後，文件系統纔會將日誌區域的Inode信息和block信息提交到對應的block group中，完成整個寫入過程。當文件系統發生異常並重啓後，e2fsck檢測程序會掃描日誌區域中的副本：如果發現還有事務單位沒有被提交，那麼磁盤上對應的block位置上的信息將被清除，以保持文件信息一致性。
writeback日誌模式
這是一種異步日誌模式，文件系統的日誌區域雖然也記錄將寫入磁盤的新文件的Inode、Block bitmap、Inode bitmap等索引信息。但是和ordered日誌模式不同的是，這些日誌信息記錄過程和文件數據的寫入過程沒有先後關聯，並且也不存在“提交”的概念。當文件系統發生異常並重啓後，e2fsck檢測程序也不會按照日誌區域的數據狀態進行一致性修復。writeback日誌模式在大多數情況下能夠提供最佳的Ext3/Ext4文件系統性能，因爲日誌功能幾乎是關閉的。
從以上三種Ext3文件系統日誌模式的簡述中，可以發現的Ext3日誌並不保證數據不丟失。實際上保證數據不丟失並不是Ext3日誌的目標，而保證數據一致性纔是Ext3日誌的主要目標。爲了達到這個目標，日誌數據甚至會主動丟棄無法復原的副本數據。
6-2-3、設置文件系統日誌級別
本小節介紹如何查看和設置Ext3/Ext4文件系統的日誌模式。首先爲了確定當前文件系統是否開啓了日誌模式，可以使用dumpe2fs命令進行查看：
# dumpe2fs /dev/sdb2
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 0e94b563-8348-4056-8770-67fa34e2b903
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
......
Journal backup: inode blocks
Journal features: (none)
日誌大小: 128M
Journal length: 32768
Journal sequence: 0x00000001
Journal start: 0
......
//以下的block group信息可以忽略可以看到Filesystem features選項中有一個has_journal關鍵信息標識，這表示當前文件系統已經開啓了日誌功能。如果沒有看到這個標記，則說明文件系統本身還沒有開啓日誌功能——這種情況下Ext3文件系統就和Ext2文件系統沒有太大區別了。
以下命令可以開啓Ext3/Ext4文件系統的日誌功能：
# tune2fs -O has_journal /dev/sdb2
tune2fs 1.41.12 (17-May-2010)
Creating journal inode: done以下命令可以關閉Ext3/Ext4文件系統的日誌功能：
# tune2fs -O ^has_journal /dev/sdb2
tune2fs 1.41.12 (17-May-2010)但必須注意這並不表示指定了具體的日誌模式，在開啓了文件系統日誌功能的情況下讀者可以在使用mount進行具體掛載時指定日誌模式。如下所示：
mount -o data=journal /dev/sdb2 /mnt/hgfs/以上命令的data參數部分可以換成ordered、writeback和journal，代表文件系統支持的三種日誌模式。設置完成後文件一同也完成了掛載。但是怎麼檢查日誌模式設置是否成功呢？讀者可以通過dmesg命令查看Linux系統的內核日誌，在日誌的最後一行會有最近一次的掛載信息，類似如下：
# dmesg
......
EXT3-fs (sdb2): using internal journal
EXT3-fs (sdb2): mounted filesystem with journal data mode
SELinux: initialized (dev sdb2, type ext3), uses xattr可以看到內核日誌信息的最後一行信息說明最近完成的內核變動操作，是按照journal日誌模式掛載sdb2分區。當然內核日誌信息包含了很多無用的信息，讀者還可以通過以下命令索引出需要查看的信息：
# dmesg | grep -B 1 "mounted filesystem"
......
sd 2:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts:
--
Microcode Update Driver: v2.00 <[email protected]>, Peter Oruba
EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts:
--
EXT3-fs (sdb2): using internal journal
EXT3-fs (sdb2): mounted filesystem with journal data mode
......當然最終我們還是要實現磁盤的永久掛載，這是就需要更改Linux操作系統中的/etc/fstab文件了。如果讀者使用的是文件系統默認的ordered日誌模式，則不需要在/etc/fstab文件中進行額外的設置。但如果不是這樣的話，讀者在設置/etc/fstab文件時，就要在其中的options列說明文件系統使用的日誌模式。類似如下所示：
# vim /etc/fstab
......
/dev/sdb2 /mnt/hgfs ext3 data=journal 0 0
......7、下文介紹
上一節我們討論了Ext3文件系統相對於Ext2文件系統最大的改進點——日誌模式。但是Ext2文件系統中另外一個問題還沒有做太多調整：因爲存儲大文件時Ext2/Ext3文件系統會啓用二級、三級甚至四級間接指針建立Inode和data block的聯繫，這樣的做法會降低文件系統上對大文件的讀寫能力。
Ext4文件系統的細節文章就不再過多介紹了，因爲系統存儲這個專題到到現在已經從最底層硬件設備開始到陣列結構再到操作系統上的文件系統進行了說明，相信讀者已經理解了爲什麼這種傳統的存儲方案被稱爲塊存儲方案了。但是真正和軟件架構有關的知識卻還一點都沒有介紹。這顯然偏離了本專題最初規劃。
對Ext4文件系統有興趣的讀者可以繼續參考Ext官方文檔（https://kernelnewbies.org/Ext4） ，從下文開始我們將轉入普遍搭建在塊存儲方案之上的關係型數據庫的相關知識介紹（主要爲MySQL數據庫），包括影響關係型數據庫性能的重要因素、如何進行關係型數據庫集羣的搭建。