當前位置:
首頁 > 知識 > 好文翻譯丨Linux 文件系統 EXT4 的前世今生

好文翻譯丨Linux 文件系統 EXT4 的前世今生

好文翻譯丨Linux 文件系統 EXT4 的前世今生

歡迎下載開源中國APP獲取更多優質文章

在先前關於Linux文件系統的文章中,我寫了一份說明書去介紹Linux文件系統,裡面有一些高級的概念,比如說,一切都是文件。我很想去深入地討論更多EXT文件系統的特性的信息。所以,首先讓我們來回答這個問題:什麼是文件系統?一個文件系統應該遵循以下特點:

1.數據存儲:文件系統主要的功能是結構化存儲和取回數據。

2.命名空間:提供一套命名和組織的方法,就是命名和結構化數據的規則。

3.安全模型:一種訪問控制的策略。

4.API:系統操控文件系統對象的函數,就像操作文件夾和文件一樣。

5.實現:一個實現以上功能的軟體。

這篇文章集中與上面清單的第一項,還有探究元數據結構---在EXT文件系統中提供數據存儲的邏輯框架。

EXT文件系統歷史

雖然是為Linux編寫的,但EXT文件系統起源於Minix操作系統,而Minix文件系統早在1987年首次發布,比Linux還早五年就已經發布了。如果我們查看EXT文件系統家族從其Minix根開始的歷史和技術演變,就會更容易理解EXT4文件系統。

Minix

當編寫原始Linux內核,Linus Torvalds需要一個文件系統,但是不想開發它。因此他簡單的使用了Minix文件系統,這是 Andrew S. Tanenbaum開發的,而且是Tanenbaum 的Minix操作系統的一部分。Minix是類Unix操作系統,為教育使用而開發。它的代碼開放使用,而且合理的授權給Torvalds,允許他將它用於Linux的初代版本。

Minix結構如下,其中大部分位於文件系統生成的分區中:

  • 引導扇區(boot sector)

    安裝於硬碟的第一個扇區。引導塊(boot block)包含一個非常小的引導記錄和一個分區表。

  • 每一個分區中的第一個塊是

    超級塊(superblock)

    ,它包含了定義其他文件系統結構的元數據,並將它們定位在分配給分區的物理磁碟上。
  • 節點點陣圖塊(inode bitmap block)

    ,它確定了哪個節點在使用以及哪個節點是空閑的。
  • 節點(inodes)

    ,它們在磁碟上有它們自己的空間。每個節點包含了一個文件的信息,包括數據塊的位置,即文件所屬的區域。
  • 區域點陣圖(zone bitmap)

    跟蹤記錄數據區域的使用和釋放。
  • 數據區域(data zone)

    ,數據實際上存儲的位置。

對於點陣圖的兩個類型來說,一個bit代表了一個特有的數據區域或者一個特有的節點。如果這個bit是0,這個區域或者節點是空閑的而且可供使用,但是如果這個bit是1,這個數據區域或者節點是在使用中的。

節點是什麼?它是索引節點(index-node)的縮寫,一個節點是在磁碟上的一個256位元組的塊,而且它存儲文件相關的數據。這些數據包括文件的大小;文件的用戶和所屬組的用戶ID;文件模式(即訪問許可權);以及三個時間戳具體說明了時間,包括:文件最後訪問時間,最後修改時間,以及節點中的數據最後修改時間。

節點也包含了:指向硬碟上文件數據所在的位置。在Minix和EXT1-3文件系統中,它是一個數據區域和塊的列表。Minix文件系統節點支持9個數據塊,7個直接指針和2個間接指針。如果你想了解的更多,這有一個很好的PDF詳細描述了Minix文件系統結構,以及在Wikipedia上對節點指針結構的快速概述。

EXT

最初的EXT文件系統(Extended)由Rémy Card編寫,並於1992年與Linux一起發布,以規避Minix文件系統的一些大小限制。其中主要的結構變化是基於Unix文件系統(UFS)的文件系統元數據,該結構也被稱為伯克利快速文件系統(FFS)。我發現很少有關於此EXT文件系統的可考究的發布信息,顯然是因為它存在重大問題,並很快被EXT2文件系統所取代。

EXT2

EXT2文件系統非常成功。它在Linux發行版中被使用了很多年,並且它是我在1997年左右開始使用Red Hat Linux 5.0時遇到的第一個文件系統。EXT2文件系統與EXT文件系統具有基本相同的元數據結構,但EXT2更具前瞻性,因為在元數據結構之間保留大量磁碟空間以供未來使用。

像Minix一樣,EXT2在其安裝的硬碟的第一個扇區中有一個引導扇區,其中包括一個非常小的引導記錄和一個分區表。在引導扇區後面有一些預留空間,它跨越引導記錄和硬碟上通常位於下一個柱面邊界上的第一個分區之間的空間。 GRUB2(可能還有GRUB1)使用這個空間作為其啟動代碼的一部分。

每個EXT2分區中的空間被劃分為多個柱面組,可以更加精細地管理數據空間。 根據我的經驗,組大小通常約為8MB。下面的圖1顯示了柱面組的基本結構。柱面中的數據分配單元是塊,其大小通常為4K。

好文翻譯丨Linux 文件系統 EXT4 的前世今生

圖1:EXT文件系統中柱面組的結構

柱面組中的第一個塊是一個超級塊,它包含定義其他文件系統結構並將其定位在物理磁碟上的元數據。 分區中的一些附加組將具有備份超級塊,但不是全部。 損壞的超級塊可以使用dd等磁碟實用程序將備份超級塊的內容複製到主超級塊。 它並不經常發生,但是多年前曾經有一個受損的超級塊,我可以使用其中一個備份超級塊來恢復其內容。 幸運的是,我已經預見到並使用dumpe2fs命令轉儲我系統上分區的描述符信息。

下面是dumpe2fs命令的部分輸出。它顯示了超級塊中包含的元數據,以及關於文件系統中前兩個柱面組的數據。

# dumpe2fs /dev/sda1
Filesystem volume name: boot
Last mounted on: /boot
Filesystem UUID: 79fc5ed8-5bbc-4dfe-8359-b7b36be6eed3
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 122160
Block count: 488192
Reserved block count: 24409
Free blocks: 376512
Free inodes: 121690
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 238
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8144
Inode blocks per group: 509
Flex block group size: 16
Filesystem created: Tue Feb 7 09:33:34 2017
Last mount time: Sat Apr 29 21:42:01 2017
Last write time: Sat Apr 29 21:42:01 2017
Mount count: 25
Maximum mount count: -1
Last checked: Tue Feb 7 09:33:34 2017
Check interval: 0 (<none>)
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)
<snip>

每個柱面組都有自己的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文件系統中非常少見,因此大多節點會只用一個或者兩個直接數據指針而且不使用間接指針。

好文翻譯丨Linux 文件系統 EXT4 的前世今生

圖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%)。

好文翻譯丨Linux 文件系統 EXT4 的前世今生

表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開源社區 的精彩文章:

PYPL 6月IDE指數榜:IntelliJ追上SublimeText,PyCharm反超Xcode
你的開源項目缺個好看的 logo?這裡有人免費幫你畫好了

TAG:OSC開源社區 |