) Lifetime writes: 594 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 32 Desired extra isize: 32 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: c780bac9-d4bf-4f35-b695-0fe35e8d2d60 Journal backup: inode blocks Journal features: journal_64bit Journal size: 32M Journal length: 8192 Journal sequence: 0x00000213 Journal start: 0 Group 0: (Blocks 0-32767) Primary superblock at 0, Group descriptors at 1-1 Reserved GDT blocks at 2-239 Block bitmap at 240 (+240) Inode bitmap at 255 (+255) Inode table at 270-778 (+270) 24839 free blocks, 7676 free inodes, 16 directories Free blocks: 7929-32767 Free inodes: 440, 470-8144 Group 1: (Blocks 32768-65535) Backup superblock at 32768, Group descriptors at 32769-32769 Reserved GDT blocks at 32770-33007 Block bitmap at 241 (bg #0 + 241) Inode bitmap at 256 (bg #0 + 256) Inode table at 779-1287 (bg #0 + 779) 8668 free blocks, 8142 free inodes, 2 directories Free blocks: 33008-33283, 33332-33791, 33974-33975, 34023-34092, 34094-34104, 34526-34687, 34706-34723, 34817-35374, 35421-35844, 35935-36355, 36357-36863, 38912-39935, 39940-40570, 42620-42623, 42655, 42674-42687, 42721-42751, 42798-42815, 42847, 42875-42879, 42918-42943, 42975, 43000-43007, 43519, 43559-44031, 44042-44543, 44545-45055, 45116-45567, 45601-45631, 45658-45663, 45689-45695, 45736-45759, 45802-45823, 45857-45887, 45919, 45950-45951, 45972-45983, 46014-46015, 46057-46079, 46112-46591, 46921-47103, 49152-49395, 50027-50355, 52237-52255, 52285-52287, 52323-52351, 52383, 52450-52479, 52518-52543, 52584-52607, 52652-52671, 52734-52735, 52743-53247 Free inodes: 8147-16288 Group 2: (Blocks 65536-98303) Block bitmap at 242 (bg #0 + 242) Inode bitmap at 257 (bg #0 + 257) Inode table at 1288-1796 (bg #0 + 1288) 6326 free blocks, 8144 free inodes, 0 directories Free blocks: 67042-67583, 72201-72994, 80185-80349, 81191-81919, 90112-94207 Free inodes: 16289-24432 Group 3: (Blocks 98304-131071)
每個柱面組都有自己的inode位圖，該位圖用於確定使用哪些inode，以及該組中哪些是空閒的。inode在每個組中都有自己的空間。每個inode都包含有關一個文件的信息，包括屬於該文件的數據塊的位置。塊位圖跟蹤文件系統中使用和釋放的數據塊。注意，上面顯示的輸出中有大量關於文件系統的數據。在很大的文件系統中，組數據可以長達數百頁。組元數據包括組中所有空閒數據塊的列表。
EXT文件系統實現了保證文件碎片最小化的數據分配策略。減少磁盤碎片化可改善文件系統的性能。這些策略將在下文的EXT4部分中進行介紹。
在某些情況下，我曾遇到的EXT2文件系統的最大問題是在崩潰後可能需要幾個小時才能恢復，因為fsck（file system check）程序需要很長時間才能找到並糾正文件系統中的任何不一致。它曾在我的一臺計算機上花費了28個小時的時間，以實現在發生崩潰到重新啟動時完全恢復磁盤 -並且這是在磁盤大小為數百兆字節下測試的結果。
EXT3
EXT3文件系統的唯一目標是克服fsck程序需要大量時間來完全恢復因文件更新操作期間發生的不正確關閉而損壞的磁盤結構的問題。EXT文件系統的唯一增加是journal，它預先記錄了將對文件系統執行的改動。磁盤結構的其餘部分和EXT2中是相同的。
EXT3中的journal並不是直接將數據寫入磁盤的數據區域，而是將文件數據及其元數據寫入到磁盤上的指定區域。一旦數據安全地存儲在硬盤上，它就可以合併到目標文件或附加到目標文件中，而這幾乎不會丟失數據。由於該數據被提交到磁盤的數據區域，因此需更新journal以便在發生系統故障時文件系統保持一致狀態，然後該journal中的所有數據都被提交。在下次啟動時，將檢查文件系統是否存在不一致性，然後將journal中剩餘的數據提交到磁盤的數據區域以完成對目標文件的更新。
日誌化確實會降低數據寫入性能，但journal提供了三種選項可供用戶在性能，數據完整性和安全性之間進行選擇。我的個人偏好是安全性，因為我的環境不需要繁重的磁盤寫入操作。
日誌函數最多可以減少在檢查硬盤驅動發現不一致性所需的時間：從幾小時（甚至幾天）到幾分鐘不等。多年來，我遇到了很多導致系統崩潰的問題。箇中細節可以填滿另一篇文章，但足以證實大多數是自我原因造成的，就像踢掉電源插頭一樣。幸運的是，EXT日誌化文件系統已將啟動恢復時間縮短到兩三分鐘。另外，自從我開始使用帶日誌功能的EXT3以來，我從來沒有遇到丟失數據的問題了。
EXT3的日誌功能可以關閉，然後作為EXT2文件系統運行。日誌功能本身仍然存在，它是空的並且是未使用的。只需使用mount命令重新掛載分區，使用type參數指定EXT2。您可以在命令行中執行此操作，這取決於您使用的是哪個文件系統，但是您可以更改/etc/fstab文件中的類型說明符，然後重新啟動。我強烈建議不要將EXT3文件系統作為EXT2使用，因為可能會丟失數據並延長恢復時間。
現有的EXT2文件系統可以通過使用以下命令添加日誌來升級到EXT3。
tune2fs -j /dev/sda1
其中/dev/sda1是驅動器和分區標識符。確保在/etc/fstab中更改文件類型說明符，並重新啟動分區或重新啟動系統以使更改生效。
EXT4
EXT4文件系統主要改善了性能，可靠性和容量。為了提升可靠性，添加了元數據和日誌校驗和。為了完成各種各樣的關鍵任務的需求，文件系統時間戳將時間間隔精確到了納秒。時間戳字段的兩個高位bit將2038年問題延續到了2446年——至少為EXT4文件系統延續了。
在EXT4中，數據分配從固定塊變成了擴展塊。一個擴展塊通過它在硬盤上的起始和結束位置來描述。這使得在一個單一節點指針條目中描述非常長的物理連續文件成為可能，它可以顯著減少大文件中的描述所有數據的位置的所需指針的數量。為了進一步減少碎片化，其他分配策略已經在EXT4中實現。
EXT4通過在磁盤上分散新創建的文件來減少碎片化，因此他們不會像早期的PC文件系統，聚集在磁盤的起始位置。文件分配算法嘗試儘量將文件均勻的覆蓋到柱面組，而且當不得不產生碎片時，儘可能地將間斷文件範圍靠近同一個文件的其他碎片，來儘可能壓縮磁頭尋找和旋轉等待時間。當一個新文件創建的時候或者當一個已有文件擴大的時候，附加策略用於預分配額外磁盤空間。它有助於保證擴大文件不會導致它直接變為碎片。新文件不會直接分配在已存在文件的後面，這也阻止了已存在文件的碎片化。
除了數據在磁盤的具體位置，EXT4使用一些功能策略，例如延遲分配，允許文件系統在分配空間之前先收集到要寫到磁盤的所有數據。這可以提高數據空間連續的概率。
之前的EXT文件系統，例如EXT2和EXT3，可以掛載EXT4，來提升一些次要性能。不幸的是，它要求關掉一些EXT4的重要的新特性，因此我不建議這種做法。
從Fedora 14開始，EXT4已經是Fedora的默認文件系統。使用在Fedroa文檔描述的過程，一個EXT3文件系統可以升級到EXT4，然而由於剩餘的EXT3元數據結構，它的性能仍然會受到影響。從EXT3升級到EXT4最好的方法是備份所有的目標文件系統分區的數據，使用mkfs命令將一個空的EXT4文件系統寫到分區，然後從備份恢復所有數據。
節點（Inode）
在之前描述過，節點是一個EXT文件系統的元數據的關鍵要素。圖2展示了節點和存儲在硬盤上的數據之間的關係。這個示意圖是目錄和單一文件的節點，在這種情況下，可能是高度碎片化文件的節點。EXT文件系統為減少碎片化而積極努力，因此你不會看到有很多間接數據塊或者數據區的文件。事實上，就像你將在下面看到的，碎片化在EXT文件系統中非常少見，因此大多節點會只用一個或者兩個直接數據指針而且不使用間接指針。
圖2：節點存儲了關於每個文件的信息和EXT文件系統對所有屬於它的數據的定位。
節點不包含文件的名稱。通過目錄項（directory entry）來訪問文件，它自己就是文件的名稱而且包含指向此節點的指針。指針的值是節點號。每個文件系統中的節點都有一個唯一的ID號，但是在同一個電腦（甚至同一個硬盤）的其他文件系統中的節點可以有相同的節點號。這會對硬連接產生一些後果，這方面內容超出了本文的範圍。
節點包含了文件的元數據，包括它的類型和權限以及它的大小。節點也包含了15個指針的空間，來描述柱面組中數據部分中的數據塊或數據區的位置和長度。12個指針提供了數據區的直接訪問，而且對處理大部分文件都是足夠的。然而，對於有大量碎片的文件，它可能必須需要一些額外的空間，以間接節點的形式描述。從技術上來講，它們不是真正的節點，因此為了方便我使用短語“間接節點（node）”。
間接節點是文件系統中一個常規的數據塊，只用於描述數據而且不用存儲元數據，因此可以支持超過15個指針。例如，一個大小為4K的塊可以支持512個4字節間接節點，允許一個單一文件包含
12（直接）+512（間接）=524個區。同樣也支持雙重或三重間接節點，但是我們一般不太可能遇到需要這麼多區的文件。對於許多陳舊的PC文件系統（諸如FAT（及其所有變體）和NTFS），碎片化一直是導致磁盤性能下降的主要問題。碎片整理本身就成為一個行業，囊括不同品牌的碎片整理軟件，其作用從非常有效到表現平平。
Linux擴展文件系統使用的數據分配策略，有助於最大限度地減少硬盤驅動器上文件的碎片，並在碎片發生時減少碎片效應。你可以在EXT文件系統上使用fsck命令來檢查整個文件系統的碎片。以下示例檢查我的主工作站的主目錄，該目錄僅有1.5％碎片化。請務必使用-n參數，因為它可以防止fsck對所掃描的文件系統執行任何操作。
fsck -fn /dev/mapper/vg_01-home
我曾經進行過一些理論上的計算，以確定磁盤碎片整理是否會導致性能顯著提高。雖然我確實做了一些假定，但我使用的磁盤性能數據來自新的300GB，Western Digital硬盤，具有2.0ms的磁軌間尋址時間。本例中的文件數量是我在計算當天存在於該文件系統中的實際數量。我確實假定每天都會觸發相當多的碎片文件（20％）。
表1: 碎片化對磁盤性能的理論上的影響
我已經做了兩次測算，每天總的附加尋址時間，一次是基於磁軌間尋址時間，這是由於EXT文件分配策略而導致大多數文件更可能出現的情況，另一種是平均尋址時間，我假定這會觸發相當於最壞的情形。
從表1可以看出，對於具有相當性能的硬盤驅動器的現代EXT文件系統來說，碎片化影響最小；對絕大多數應用程序來說可以忽略不計。你可以將實際環境中的數據插入到你自己的類似電子表格中，以得到你對性能影響的預期。這種計算方式很可能不會代表實際性能，但它可以提供對碎片話及其對系統的理論上的影響的一些洞察力。
我的大部分分區大約1.5％或1.6％碎片化;我確實有一個3.3％碎片化的分區，但這是一個大的，128GB的文件系統，擁有少於100個非常大的ISO映像文件;多年來，我不得不多次擴展此分區，因為它太滿了。
這並不是說某些應用程序環境不需要更少的碎片文件的保證。EXT文件系統可以由知識淵博的管理員進行調整，他們可以調整參數以補償特定的工作負載類型。這可以在文件系統被創建時或之後使用
tune2fs命令來完成。應對每次調優改動的結果進行測試，細緻地記錄並進行分析，以確保對目標環境達到最佳性能。在最差的情況下，如果性能無法提升到所需的水平，則可能有更適合特定工作負載的其他文件系統類型。請記住，在單個主機系統上混用文件系統類型以匹配每個文件系統上的負載是很常見的。由於在大多數EXT文件系統中碎片數量很少，因此不需要進行碎片整理。無論如何，EXT文件系統都沒有安全的碎片整理工具。目前有幾個工具可以讓你檢查單個文件的碎片狀況或文件系統中剩餘空閒空間的碎片化狀態。有一個工具，e4defrag，它將在可用空間允許的前提下對文件、目錄或文件系統進行儘可能地碎片化整理。顧名思義，它只適用於EXT4文件系統中的文件，並且存在一些侷限性。
如果有必要對EXT文件系統執行完全的碎片整理，則僅有一種方法可以可靠地工作。你必須移動文件系統中的所有文件以進行碎片整理，以確保在將文件安全複製到其他位置後將其刪除。如果可能的話，你可以增加文件系統的大小來輔助減少將來的碎片產生。然後將文件複製回目標文件系統。即使這樣做並不能保證所有的文件都會被完全去碎片化。
結論
20多年來，EXT文件系統一直是許多Linux發行版的默認文件系統。它們需要少量的維護就能提供穩定性、高容量、可靠性和性能。我嘗試過其他文件系統，但總是回到EXT。毫無疑問，EXT4文件系統應該用於大多數Linux系統，除非有令人信服的理由去使用另一個文件系統。
關於作者
David Both。David Both居住在北卡羅來納州的Raleigh，是Linux和開源的支持者。他在IT行業工作了四十多年，並在IBM教授OS/2了二十多年。在IBM工作期間，他在1981年為最初的IBM PC編寫了第一期培訓課程。他曾為紅帽教授RHCE課程，並曾在MCI Worldcom，思科和北卡羅萊納州工作。他在Linux和開源軟件方面工作了近20年。David為OS/2雜誌，Linux雜誌，Linux週刊和OpenSource.com撰寫了文章。他與思科同事合作撰寫的文章“Complete Kickstart”在2008年Linux雜誌十大最佳系統管理文章排行榜中名列第九。
閱讀更多 OSC開源社區 的文章
