Linux的EXT4 文件系統(tǒng)的歷史、特性以及更優(yōu)實(shí)踐
讓我們大概地從 EXT4 的歷史、特性以及***實(shí)踐這幾個(gè)方面來學(xué)習(xí)它和之前的幾代 EXT 文件系統(tǒng)有何不同。
在之前關(guān)于 Linux 文件系統(tǒng)的文章里，我寫過一篇 Linux 文件系統(tǒng)介紹 和一些更高級(jí)的概念例如 一切都是文件?，F(xiàn)在我想要更深入地了解 EXT 文件系統(tǒng)的特性的詳細(xì)內(nèi)容，但是首先讓我們來回答一個(gè)問題，“什么樣才算是一個(gè)文件系統(tǒng) ?” 一個(gè)文件系統(tǒng)應(yīng)該涵蓋以下所有特點(diǎn)：
- 數(shù)據(jù)存儲(chǔ)： 對(duì)于任何一個(gè)文件系統(tǒng)來說，一個(gè)最主要的功能就是能夠被當(dāng)作一個(gè)結(jié)構(gòu)化的容器來存儲(chǔ)和獲取數(shù)據(jù)。
- 命名空間： 命名空間是一個(gè)提供了用于命名與組織數(shù)據(jù)的命名規(guī)則和數(shù)據(jù)結(jié)構(gòu)的方法學(xué)。
- 安全模型： 一個(gè)用于定義訪問權(quán)限的策略。
- API： 操作這個(gè)系統(tǒng)的對(duì)象的系統(tǒng)功能調(diào)用，這些對(duì)象諸如目錄和文件。
- 實(shí)現(xiàn)： 能夠?qū)崿F(xiàn)以上幾點(diǎn)的軟件。
本文內(nèi)容的討論主要集中于上述幾點(diǎn)中的***項(xiàng)，并探索為一個(gè) EXT 文件系統(tǒng)的數(shù)據(jù)存儲(chǔ)提供邏輯框架的元數(shù)據(jù)結(jié)構(gòu)。
EXT 文件系統(tǒng)歷史
雖然 EXT 文件系統(tǒng)是為 Linux 編寫的，但其真正起源于 Minix 操作系統(tǒng)和 Minix 文件系統(tǒng)，而 Minix 最早發(fā)布于 1987，早于 Linux 5 年。如果我們從 EXT 文件系統(tǒng)大家族的 Minix 起源來觀察其歷史與技術(shù)發(fā)展那么理解 EXT4 文件系統(tǒng)就會(huì)簡(jiǎn)單得多。
Minix
當(dāng) Linux Torvalds 在寫最初的 Linux 內(nèi)核的時(shí)候，他需要一個(gè)文件系統(tǒng)但是他又不想自己寫一個(gè)。于是他簡(jiǎn)單地把 Minix 文件系統(tǒng) 加了進(jìn)去，這個(gè) Minix 文件系統(tǒng)是由 Andrew S. Tanenbaum 寫的，同時(shí)它也是 Tanenbaum 的 Minix 操作系統(tǒng)的一部分。Minix 是一個(gè)類 Unix 風(fēng)格的操作系統(tǒng)，最初編寫它的原因是用于教育用途。Minix 的代碼是自由可用的并有適當(dāng)?shù)脑S可協(xié)議，所以 Torvalds 可以把它用 Linux 的最初版本里。
Minix 有以下這些結(jié)構(gòu)，其中的大部分位于生成文件系統(tǒng)的分區(qū)中：
- 引導(dǎo)扇區(qū) 是硬盤安裝后的***個(gè)扇區(qū)。這個(gè)引導(dǎo)塊包含了一個(gè)非常小的引導(dǎo)記錄和一個(gè)分區(qū)表。
- 每一個(gè)分區(qū)的***個(gè)塊都是一個(gè)包含了元數(shù)據(jù)的超級(jí)塊(superblock) ，這些元數(shù)據(jù)定義了其他的文件系統(tǒng)結(jié)構(gòu)并將其定位于物理硬盤的具體分區(qū)上。
- 一個(gè) inode 位圖塊 決定了哪些 inode 是在使用中的，哪一些是未使用的。
- inode 在硬盤上有它們自己的空間。每一個(gè) inode 都包含了一個(gè)文件的信息，包括其所處的數(shù)據(jù)塊的位置，也就是該文件所處的區(qū)域。
- 一個(gè) 區(qū)位圖 用于保持追蹤數(shù)據(jù)區(qū)域的使用和未使用情況。
- 一個(gè) 數(shù)據(jù)區(qū), 這里是數(shù)據(jù)存儲(chǔ)的地方。
對(duì)上述了兩種位圖類型來說，一個(gè)位(bit)表示一個(gè)指定的數(shù)據(jù)區(qū)或者一個(gè)指定的 inode。 如果這個(gè)位是 0 則表示這個(gè)數(shù)據(jù)區(qū)或者這個(gè) inode 是未使用的，如果是 1 則表示正在使用中。
那么，inode 又是什么呢 ? 就是 index-node(索引節(jié)點(diǎn))的簡(jiǎn)寫。 inode 是位于磁盤上的一個(gè) 256 字節(jié)的塊，用于存儲(chǔ)和該 inode 對(duì)應(yīng)的文件的相關(guān)數(shù)據(jù)。這些數(shù)據(jù)包含了文件的大小、文件的所有者和所屬組的用戶 ID、文件模式(即訪問權(quán)限)以及三個(gè)時(shí)間戳用于指定：該文件***的訪問時(shí)間、該文件的***修改時(shí)間和該 inode 中的數(shù)據(jù)的***修改時(shí)間。
同時(shí)，這個(gè) inode 還包含了位置數(shù)據(jù)，指向了其所對(duì)應(yīng)的文件數(shù)據(jù)在硬盤中的位置。在 Minix 和 EXT 1-3 文件系統(tǒng)中，這是一個(gè)數(shù)據(jù)區(qū)和塊的列表。Minix 文件系統(tǒng)的 inode 支持 9 個(gè)數(shù)據(jù)塊，包括 7 個(gè)直接數(shù)據(jù)塊和 2 個(gè)間接數(shù)據(jù)塊。如果你想要更深入的了解，這里有一個(gè)優(yōu)秀的 PDF 詳細(xì)地描述了 Minix 文件系統(tǒng)結(jié)構(gòu) 。同時(shí)你也可以在維基百科上對(duì) inode 指針結(jié)構(gòu) 做一個(gè)快速了解。
EXT
原生的 EXT 文件系統(tǒng) (意即擴(kuò)展的(extended)) 是由 Rémy Card 編寫并于 1992 年與 Linux 一同發(fā)行。主要是為了克服 Minix 文件系統(tǒng)中的一些文件大小限制的問題。其中，最主要的結(jié)構(gòu)變化就是文件系統(tǒng)中的元數(shù)據(jù)。它基于 Unix 文件系統(tǒng) (UFS)，其也被稱為伯克利快速文件系統(tǒng)(FFS)。我發(fā)現(xiàn)只有很少一部分關(guān)于 EXT 文件系統(tǒng)的發(fā)行信息是可以被確證的，顯然這是因?yàn)槠浯嬖谥鴩?yán)重的問題，并且它很快地被 EXT2 文件系統(tǒng)取代了。
EXT2
EXT2 文件系統(tǒng) 就相當(dāng)?shù)爻晒Γ?Linux 發(fā)行版中存活了多年。它是我在 1997 年開始使用 Red Hat Linux 5.0 時(shí)接觸的***個(gè)文件系統(tǒng)。實(shí)際上，EXT2 文件系統(tǒng)有著和 EXT 文件系統(tǒng)基本相同的元數(shù)據(jù)結(jié)構(gòu)。然而 EXT2 更高瞻遠(yuǎn)矚，因?yàn)槠湓獢?shù)據(jù)結(jié)構(gòu)之間留有很多供將來使用的磁盤空間。
和 Minix 類似，EXT2 也有一個(gè)引導(dǎo)扇區(qū) ，它是硬盤安裝后的***個(gè)扇區(qū)。它包含了非常小的引導(dǎo)記錄和一個(gè)分區(qū)表。接著引導(dǎo)扇區(qū)之后是一些保留的空間，它填充了引導(dǎo)記錄和硬盤驅(qū)動(dòng)器上的***個(gè)分區(qū)(通常位于下一個(gè)柱面)之間的空間。GRUB2 - 也可能是 GRUB1 - 將此空間用于其部分引導(dǎo)代碼。
每個(gè) EXT2 分區(qū)中的空間被分為柱面組(cylinder group)，它允許更精細(xì)地管理數(shù)據(jù)空間。 根據(jù)我的經(jīng)驗(yàn)，每一組大小通常約為 8MB。 下面的圖 1 顯示了一個(gè)柱面組的基本結(jié)構(gòu)。 柱面中的數(shù)據(jù)分配單元是塊，通常大小為 4K。
圖 1： EXT 文件系統(tǒng)中的柱面組的結(jié)構(gòu)
柱面組中的***個(gè)塊是一個(gè)超級(jí)塊(superblock)，它包含了元數(shù)據(jù)，定義了其它文件系統(tǒng)的結(jié)構(gòu)并將其定位于物理硬盤的具體分區(qū)上。分區(qū)中有一些柱面組還會(huì)有備用超級(jí)塊，但并不是所有的柱面組都有。我們可以使用例如 dd 等磁盤工具來拷貝備用超級(jí)塊的內(nèi)容到主超級(jí)塊上，以達(dá)到修復(fù)損壞的超級(jí)塊的目的。雖然這種情況不會(huì)經(jīng)常發(fā)生，但是在幾年前我的一個(gè)超級(jí)塊損壞了，我就是用這種方法來修復(fù)的。幸好，我很有先見之明地使用了 dumpe2fs 命令來備份了我的系統(tǒng)上的分區(qū)描述符信息。
以下是 dumpe2fs 命令的一部分輸出。這部分輸出主要是超級(jí)塊上包含的一些元數(shù)據(jù)，同時(shí)也是文件系統(tǒng)上的前兩個(gè)柱面組的數(shù)據(jù)。
- # 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)
- <截?cái)?gt;
每一個(gè)柱面組都有自己的 inode 位圖，用于判定該柱面組中的哪些 inode 是使用中的而哪些又是未被使用的。每一個(gè)柱面組的 inode 都有它們自己的空間。每一個(gè) inode 都包含了一個(gè)文件的相關(guān)信息，包括屬于該文件的數(shù)據(jù)塊的位置。而塊位圖紀(jì)錄了文件系統(tǒng)中的使用中和非使用中的數(shù)據(jù)塊。請(qǐng)注意，在上面的輸出中有大量關(guān)于文件系統(tǒng)的數(shù)據(jù)。在非常大的文件系統(tǒng)上，柱面組的數(shù)據(jù)可以多達(dá)數(shù)百頁(yè)的長(zhǎng)度。柱面組的元數(shù)據(jù)包括組中所有空閑數(shù)據(jù)塊的列表。
EXT 文件系統(tǒng)實(shí)現(xiàn)了數(shù)據(jù)分配策略以確保產(chǎn)生最少的文件碎片。減少文件碎片可以提高文件系統(tǒng)的性能。這些策略會(huì)在下面的 EXT4 中描述到。
我所遇見的關(guān)于 EXT2 文件系統(tǒng)***的問題是 fsck (文件系統(tǒng)檢查) 程序這一環(huán)節(jié)占用了很長(zhǎng)一段時(shí)間來定位和校準(zhǔn)文件系統(tǒng)中的所有的不一致性，從而導(dǎo)致在系統(tǒng)崩潰(crash)后其會(huì)花費(fèi)了數(shù)個(gè)小時(shí)來修復(fù)。有一次我的其中一臺(tái)電腦在崩潰后重新啟動(dòng)時(shí)共花費(fèi)了 28 個(gè)小時(shí)恢復(fù)磁盤，而且并且是在磁盤被檢測(cè)量只有幾百兆字節(jié)大小的情況下。
EXT3
EXT3 文件系統(tǒng)是應(yīng)一個(gè)目標(biāo)而生的，就是克服 fsck 程序需要完全恢復(fù)在文件更新操作期間發(fā)生的不正確關(guān)機(jī)而損壞的磁盤結(jié)構(gòu)所需的大量時(shí)間。它對(duì) EXT 文件系統(tǒng)的唯一新增功能就是 日志，它將提前記錄將對(duì)文件系統(tǒng)執(zhí)行的更改。 EXT3 的磁盤結(jié)構(gòu)的其余部分與 EXT2 中的相同。
除了同先前的版本一樣直接寫入數(shù)據(jù)到磁盤的數(shù)據(jù)區(qū)域外，EXT3 上的日志會(huì)將文件數(shù)據(jù)隨同元數(shù)據(jù)寫入到磁盤上的一個(gè)指定數(shù)據(jù)區(qū)域。一旦這些(日志)數(shù)據(jù)安全地到達(dá)硬盤，它就可以幾乎零丟失率地被合并或被追加到目標(biāo)文件上。當(dāng)這些數(shù)據(jù)被提交到磁盤上的數(shù)據(jù)區(qū)域上，這些日志就會(huì)隨即更新，這樣在日志中的所有數(shù)據(jù)提交之前，系統(tǒng)發(fā)生故障時(shí)文件系統(tǒng)將保持一致狀態(tài)。在下次啟動(dòng)時(shí)，將檢查文件系統(tǒng)的不一致性，然后將仍保留在日志中的數(shù)據(jù)提交到磁盤的數(shù)據(jù)區(qū)，以完成對(duì)目標(biāo)文件的更新。
日志功能確實(shí)降低了數(shù)據(jù)寫入性能，但是有三個(gè)可用于日志的選項(xiàng)，允許用戶在性能和數(shù)據(jù)完整性、安全性之間進(jìn)行選擇。 我的個(gè)人更偏向于選擇安全性，因?yàn)槲业沫h(huán)境不需要大量的磁盤寫入活動(dòng)。
日志功能將失敗后檢查硬盤驅(qū)動(dòng)器所需的時(shí)間從幾小時(shí)(甚至幾天)減少到了幾分鐘。 多年來，我遇到了很多導(dǎo)致我的系統(tǒng)崩潰的問題。要詳細(xì)說的話恐怕還得再寫一篇文章，但這里需要說明的是大多數(shù)是我自己造成的，就比如不小心踢掉電源插頭。 幸運(yùn)的是，EXT 日志文件系統(tǒng)將啟動(dòng)恢復(fù)時(shí)間縮短到兩三分鐘。此外，自從我開始使用帶日志記錄的 EXT3，我從來沒有遇到丟失數(shù)據(jù)的問題。
EXT3 的日志功能可以關(guān)閉，然后其功能就等同于 EXT2 文件系統(tǒng)了。 該日志本身仍然是存在的，只是狀態(tài)為空且未使用。 只需在 mount 命令中使用文件系統(tǒng)類型參數(shù)來重新掛載即可指定為 EXT2。 你可以從命令行執(zhí)行此操作，但是具體還是取決于你正在使用的文件系統(tǒng)，不過你也可以更改 /etc/fstab 文件中的類型說明符，然后重新啟動(dòng)。 我強(qiáng)烈建議不要將 EXT3 文件系統(tǒng)掛載為 EXT2 ，因?yàn)檫@會(huì)有丟失數(shù)據(jù)和增加恢復(fù)時(shí)間的潛在可能性。
EXT2 文件系統(tǒng)可以使用如下命令來通過日志升級(jí)到 EXT3 。
- tune2fs -j /dev/sda1
/dev/sda1 表示驅(qū)動(dòng)器和分區(qū)的標(biāo)識(shí)符。同時(shí)要注意修改 /etc/fstab 中的文件系統(tǒng)類型標(biāo)識(shí)符并重新掛載分區(qū)，或者重啟系統(tǒng)以確保修改生效。
EXT4
EXT4 文件系統(tǒng)主要提高了性能、可靠性和容量。為了提高可靠性，它新增了元數(shù)據(jù)和日志校驗(yàn)和。同時(shí)為了滿足各種關(guān)鍵任務(wù)要求，文件系統(tǒng)新增了納秒級(jí)別的時(shí)間戳，并在時(shí)間戳字段中添加了兩個(gè)高位來延緩時(shí)間戳的 2038 年問題 ，這樣 EXT4 文件系統(tǒng)至少可用到 2446 年。
在 EXT4 中，數(shù)據(jù)分配從固定塊改為擴(kuò)展盤區(qū)(extent)方式，擴(kuò)展盤區(qū)由硬盤驅(qū)動(dòng)器上的開始和結(jié)束位置來描述。這使得可以在單個(gè) inode 指針條目中描述非常長(zhǎng)的物理上連續(xù)的文件，這可以顯著減少描述大文件中所有數(shù)據(jù)的位置所需的指針數(shù)。其它在 EXT4 中已經(jīng)實(shí)施的分配策略可以進(jìn)一步減少碎片化。
EXT4 通過將新創(chuàng)建的文件散布在磁盤上，使其不會(huì)像早期的 PC 文件系統(tǒng)一樣全部聚集在磁盤起始位置，從而減少了碎片。文件分配算法嘗試在柱面組中盡可能均勻地散布文件，并且當(dāng)文件(由于太大)需要分段存儲(chǔ)時(shí)，使不連續(xù)的文件擴(kuò)展盤區(qū)盡可能靠近同一文件中的其他部分，以盡可能減少磁頭尋道和電機(jī)旋轉(zhuǎn)等待時(shí)間。當(dāng)創(chuàng)建新文件或擴(kuò)展現(xiàn)有文件時(shí)，使用其它策略來預(yù)先分配額外的磁盤空間。這有助于確保擴(kuò)展文件時(shí)不會(huì)自動(dòng)導(dǎo)致其分段。新文件不會(huì)緊挨這現(xiàn)有文件立即分配空間，這也可以防止現(xiàn)有文件的碎片化。
除了磁盤上數(shù)據(jù)的實(shí)際位置外，EXT4 使用諸如延遲分配的功能策略，以允許文件系統(tǒng)在分配空間之前收集到所有正在寫入磁盤的數(shù)據(jù)，這可以提高數(shù)據(jù)空間連續(xù)的可能性。
較舊的 EXT 文件系統(tǒng)(如 EXT2 和 EXT3)可以作為 EXT4 進(jìn)行 mount ，以使其性能獲得較小的提升。但不幸的是，這需要關(guān)閉 EXT4 的一些重要的新功能，所以我建議不要這樣做。
自 Fedora 14 以來，EXT4 一直是 Fedora 的默認(rèn)文件系統(tǒng)。我們可以使用 Fedora 文檔中描述的 流程 將 EXT3 文件系統(tǒng)升級(jí)到 EXT4，但是由于仍然存留的之前的 EXT3 元數(shù)據(jù)結(jié)構(gòu)，它的性能仍將受到影響。從 EXT3 升級(jí)到 EXT4 的***方法是備份目標(biāo)文件系統(tǒng)分區(qū)上的所有數(shù)據(jù)，使用 mkfs 命令將空 EXT4 文件系統(tǒng)寫入分區(qū)，然后從備份中恢復(fù)所有數(shù)據(jù)。
Inode
之前介紹過的 inode 是 EXT 文件系統(tǒng)中的元數(shù)據(jù)的關(guān)鍵組件。 圖 2 顯示了 inode 和存儲(chǔ)在硬盤驅(qū)動(dòng)器上的數(shù)據(jù)之間的關(guān)系。 該圖是單個(gè)文件的目錄和 inode，在這種情況下，可能會(huì)產(chǎn)生高度碎片化。 EXT 文件系統(tǒng)可以主動(dòng)地減少碎片，所以不太可能會(huì)看到有這么多間接數(shù)據(jù)塊或擴(kuò)展盤區(qū)的文件。 實(shí)際上，你在下面將會(huì)看到，EXT 文件系統(tǒng)中的碎片非常低，所以大多數(shù) inode 只使用一個(gè)或兩個(gè)直接數(shù)據(jù)指針，而不使用間接指針。
圖 2 ：inode 存儲(chǔ)有關(guān)每個(gè)文件的信息，并使 EXT 文件系統(tǒng)能夠查找屬于它的所有數(shù)據(jù)。
inode 不包含文件的名稱。通過目錄項(xiàng)訪問文件，目錄項(xiàng)本身就是文件的名稱，并包含指向 inode 的指針。該指針的值是 inode 號(hào)。文件系統(tǒng)中的每個(gè) inode 都具有唯一的 ID 號(hào)，但同一臺(tái)計(jì)算機(jī)上的其它文件系統(tǒng)(甚至是相同的硬盤驅(qū)動(dòng)器)中的 inode 可以具有相同的 inode 號(hào)。這對(duì) 硬鏈接 存在影響，但是這個(gè)討論超出了本文的范圍。
inode 包含有關(guān)該文件的元數(shù)據(jù)，包括其類型和權(quán)限以及其大小。 inode 還包含 15 個(gè)指針的空位，用于描述柱面組數(shù)據(jù)部分中數(shù)據(jù)塊或擴(kuò)展盤區(qū)的位置和長(zhǎng)度。12 個(gè)指針提供對(duì)數(shù)據(jù)擴(kuò)展盤區(qū)的直接訪問，應(yīng)該足以滿足大多數(shù)文件的需求。然而，對(duì)于具有明顯分段的文件，需要以間接節(jié)點(diǎn)(node)的形式提供一些額外的容量——從技術(shù)上講，這些不是真正的“inode”，所以為了方便起見我在這里使用這個(gè)術(shù)語(yǔ)“節(jié)點(diǎn)(node)”。
間接節(jié)點(diǎn)是文件系統(tǒng)中的正常數(shù)據(jù)塊，它僅用于描述數(shù)據(jù)而不用于存儲(chǔ)元數(shù)據(jù)，因此可以支持超過 15 個(gè)條目。例如，4K 的塊大小可以支持 512 個(gè) 4 字節(jié)的間接節(jié)點(diǎn)，允許單個(gè)文件有 12(直接)+ 512(間接)= 524 個(gè)擴(kuò)展盤區(qū)。還支持雙重和三重間接節(jié)點(diǎn)，但我們大多數(shù)人不太可能遇到需要那么多擴(kuò)展盤區(qū)的文件。
數(shù)據(jù)碎片
對(duì)于許多較舊的 PC 文件系統(tǒng)，如 FAT(及其所有變體)和 NTFS，碎片一直是導(dǎo)致磁盤性能下降的重大問題。 碎片整理本身就成為一個(gè)行業(yè)，有各種品牌的整理軟件，其效果范圍從非常有效到僅僅是微乎其微。
Linux 的擴(kuò)展文件系統(tǒng)使用數(shù)據(jù)分配策略，有助于最小化硬盤驅(qū)動(dòng)器上的文件碎片，并在發(fā)生碎片時(shí)減少碎片的影響。 你可以使用 EXT 文件系統(tǒng)上的 fsck 命令檢查整個(gè)文件系統(tǒng)的碎片。 以下示例檢查我的主工作站的家目錄，只有 1.5% 的碎片。 確保使用 -n 參數(shù)，因?yàn)樗鼤?huì)防止 fsck 對(duì)掃描的文件系統(tǒng)采取任何操作。
- fsck -fn /dev/mapper/vg_01-home
我曾經(jīng)進(jìn)行過一些理論計(jì)算，以確定磁盤碎片整理是否會(huì)產(chǎn)生任何明顯的性能提升。 我做了一些假設(shè)條件，我使用的磁盤性能數(shù)據(jù)來自一個(gè)新的 300GB 的西部數(shù)字硬盤驅(qū)動(dòng)器，具有 2.0ms 的軌到軌尋道時(shí)間。 此示例中的文件數(shù)是我在計(jì)算的當(dāng)天的文件系統(tǒng)中存在的實(shí)際數(shù)。 我假設(shè)每天有相當(dāng)大量的碎片化文件(約 20%)會(huì)被用到。
| 全部文件 | 271,794 |
|---|---|
| 碎片率 % | 5.00% |
| 不連續(xù)數(shù) | 13,590 |
| % 每天用到的碎片化文件 | 20% （假設(shè)） |
| 額外尋道次數(shù) | 2,718 |
| 平均尋道時(shí)間 | 10.90 ms |
| 每天全部的額外尋道時(shí)間 | 29.63 sec |
| 0.49 min | |
| 軌到軌尋道時(shí)間 | 2.00 ms |
| 每天全部的額外尋道時(shí)間 | 5.44 sec |
| 0.091 min |
表 1: 碎片對(duì)磁盤性能的理論影響
我對(duì)每天的全部的額外尋道時(shí)間進(jìn)行了兩次計(jì)算，一次是軌到軌尋道時(shí)間，這是由于 EXT 文件分配策略而導(dǎo)致大多數(shù)文件最可能的情況，一個(gè)是平均尋道時(shí)間，我假設(shè)這是一個(gè)合理的最壞情況。
從表 1 可以看出，對(duì)絕大多數(shù)應(yīng)用程序而言，碎片化甚至對(duì)性能適中的硬盤驅(qū)動(dòng)器上的現(xiàn)代 EXT 文件系統(tǒng)的影響是微乎其微的。您可以將您的環(huán)境中的數(shù)字插入到您自己的類似電子表格中，以了解你對(duì)性能影響的期望。這種類型的計(jì)算不一定能夠代表實(shí)際的性能，但它可以提供一些對(duì)碎片化及其對(duì)系統(tǒng)的理論影響的洞察。
我的大部分分區(qū)的碎片率都在 1.5% 左右或 1.6%，我有一個(gè)分區(qū)有 3.3% 的碎片，但是這是一個(gè)大約 128GB 文件系統(tǒng)，具有不到 100 個(gè)非常大的 ISO 映像文件;多年來，我擴(kuò)展過該分區(qū)幾次，因?yàn)樗呀?jīng)太滿了。
這并不是說一些應(yīng)用的環(huán)境并不需要更少的碎片的環(huán)境。 EXT 文件系統(tǒng)可以由有經(jīng)驗(yàn)和知識(shí)的管理員小心調(diào)整，管理員可以針對(duì)特定的工作負(fù)載類型調(diào)整參數(shù)。這個(gè)工作可以在文件系統(tǒng)創(chuàng)建的時(shí)候或稍后使用 tune2fs 命令時(shí)完成。每一次調(diào)整變化的結(jié)果應(yīng)進(jìn)行測(cè)試，精心的記錄和分析，以確保目標(biāo)環(huán)境的***性能。在最壞的情況下，如果性能不能提高到期望的水平，則其他文件系統(tǒng)類型可能更適合特定的工作負(fù)載。并記住，在單個(gè)主機(jī)系統(tǒng)上混用文件系統(tǒng)類型以匹配每個(gè)文件系統(tǒng)上的不同負(fù)載是常見的。
由于大多數(shù) EXT 文件系統(tǒng)的碎片數(shù)量較少，因此無需進(jìn)行碎片整理。目前，EXT 文件系統(tǒng)沒有安全的碎片整理工具。有幾個(gè)工具允許你檢查單個(gè)文件的碎片程度或文件系統(tǒng)中剩余可用空間的碎片程度。有一個(gè)工具，e4defrag，它可以對(duì)允許使用的剩余可用空間、目錄或文件系統(tǒng)進(jìn)行碎片整理。顧名思義，它只適用于 EXT4 文件系統(tǒng)中的文件，并且它還有一其它的些限制。
如果有必要在 EXT 文件系統(tǒng)上執(zhí)行完整的碎片整理，則只有一種方法能夠可靠地工作。你必須將文件系統(tǒng)中的所有要進(jìn)行碎片整理的文件移動(dòng)從而進(jìn)行碎片整理，并在確保安全復(fù)制到其他位置后將其刪除。如果可能，你可以增加文件系統(tǒng)的大小，以幫助減少將來的碎片。然后將文件復(fù)制回目標(biāo)文件系統(tǒng)。但是其實(shí)即使這樣也不能保證所有文件都被完全去碎片化。
總結(jié)
EXT 文件系統(tǒng)在一些 Linux 發(fā)行版本上作為默認(rèn)文件系統(tǒng)已經(jīng)超過二十多年了。它們用最少的維護(hù)代價(jià)提供了穩(wěn)定性、高可用性、可靠性和性能。我嘗試過一些其它的文件系統(tǒng)但最終都還是回歸到 EXT。每一個(gè)我在工作中使用到 Linux 的地方都使用到了 EXT 文件系統(tǒng)，同時(shí)我發(fā)現(xiàn)了它們適用于任何主流負(fù)載。毫無疑問，EXT4 文件系統(tǒng)應(yīng)該被用于大部分的 Linux 文件系統(tǒng)上，除非我們有明顯需要使用其它文件系統(tǒng)的理由。
