系統管理員很重要的任務之一就是管理好自己的磁碟檔案系統，每個分割槽不可太大也不能太小， 太大會造成磁碟容量的浪費，太小則會產生檔案無法儲存的困擾。此外，我們在前面幾章談到的檔案許可權與屬性中， 這些許可權與屬性分別記錄在檔案系統的哪個區塊內？這就得要談到 filesystem 中的 inode 與 block 了。同時，為了虛擬化與大容量磁碟， 現在的 CentOS 7預設使用大容量效能較佳的 xfs 當預設檔案系統了！這也得了解一下。 在本章我們的重點在於如何製作檔案系統，包括分割槽、格式化與掛載等，是很重要的一個章節喔！

一、認識 Linux 檔案系統

Linux 最傳統的磁碟檔案系統 （filesystem） 使用的是 EXT2 這個啦！所以要了解 Linux 的檔案系統就得要由認識 EXT2 開始！ 而檔案系統是建立在磁碟上面的，因此我們得了解磁碟的物理組成才行。下面只會很快的複習這兩部份。 重點在於 inode, block 還有 superblock 等檔案系統的基本部分喔！

1，磁碟組成與分割槽的複習

 

由於各項磁碟的物理組成我們在第零章裡面就介紹過， 同時第二章也談過分割槽的概念了，所以這個小節我們就拿之前的重點出來介紹就好了！ ^_^。好了，首先說明一下磁碟的物理組成，整顆磁碟的組成主要有：

圓形的碟片（主要記錄資料的部分）；

機械手臂，與在機械手臂上的磁頭（可讀寫碟片上的資料）；

主軸馬達，可以轉動碟片，讓機械手臂的磁頭在碟片上讀寫資料。

從上面我們知道資料儲存與讀取的重點在於碟片，而碟片上的物理組成則為（假設此磁碟為單碟片）：

扇區（Sector）為最小的物理儲存單位，且依據磁碟設計的不同，目前主要有 512Bytes與 4K 兩種格式；

將扇區組成一個圓，那就是柱面（Cylinder）；

早期的分割槽主要以柱面為最小分割槽單位，現在的分割槽通常使用扇區為最小分割槽單位（每個扇區都有其號碼喔，就好像座位一樣）；

磁碟分割槽表主要有兩種格式，一種是限制較多的 MBR 分割槽表，一種是較新且限制較少的GPT 分割槽表。

MBR 分割槽表中，第一個扇區最重要，裡面有：（1）主要開機區（Master boot record,MBR）及分割槽表（partition table）， 其中 MBR 佔有 446 Bytes，而 partition table 則佔有 64 Bytes。

GPT 分割槽表除了分割槽數量擴充較多之外，支援的磁碟容量也可以超過 2TB。

 

至於磁碟的檔名部份，基本上，所有實體磁碟的檔名都已經被模擬成 /dev/sd[a-p] 的格式，第一顆磁碟檔名為 /dev/sda。 而分割槽的檔名若以第一顆磁碟為例，則為 /dev/sda[1-128] 。除了實體磁碟之外，虛擬機器的磁碟通常為 /dev/vd[a-p] 的格式。 若有使用到軟體磁碟陣列的話，那還有 /dev/md[0-128] 的磁碟檔名。使用的是 LVM 時，檔名則為/dev/VGNAME/LVNAME 等格式。 關於軟體磁碟陣列與 LVM 我們會在後面繼續介紹，這裡主要介紹的以實體磁碟及虛擬磁碟為主喔！

/dev/sd[a-p][1-128]：為實體磁碟的磁碟檔名；

/dev/vd[a-d][1-128]：為虛擬磁碟的磁碟檔名

複習完物理組成後，來複習一下磁碟分割槽吧！如前所述，以前磁碟分割槽最小單位經常是柱面，但 CentOS 7 的分割槽軟體， 已經將最小單位改成扇區了，所以容量大小的分割槽可以切的更細～此外，由於新的大容量磁碟大多得要使用 GPT 分割槽表才能夠使用全部的容量， 因此過去那個 MBR 的傳統磁碟分割槽表限制就不會存在了。不過，由於還是有小磁碟啊！因此， 你在處理分割槽的時候，還是得要先查詢一下，你的分割槽是 MBR 的分割槽？還是 GPT 的分割槽？建議強制使用 GPT 分割槽喔！

 

2，檔案系統特性

 

我們都知道磁碟分割槽完畢後還需要進行格式化（format），之後作業系統才能夠使用這個檔案系統。 為什麼需要進行“格式化”呢？這是因為每種作業系統所設定的檔案屬性/許可權並不相同， 為了存放這些檔案所需的資料，因此就需要將分割槽進行格式化，以成為作業系統能夠利用的“檔案系統格式（filesystem）”。

由此我們也能夠知道，每種作業系統能夠使用的檔案系統並不相同。 舉例來說，windows 98以前的微軟作業系統主要利用的檔案系統是 FAT （或 FAT16），windows 2000 以後的版本有所謂的 NTFS 檔案系統，至於 Linux 的正統檔案系統則為 Ext2 （Linux second extendedfile system, ext2fs）這一個。此外，在預設的情況下，windows 作業系統是不會認識 Linux的 Ext2 的。

傳統的磁碟與檔案系統之應用中，一個分割槽就是隻能夠被格式化成為一個檔案系統，所以我們可以說一個 filesystem 就是一個 partition。但是由於新技術的利用，例如我們常聽到的LVM與軟體磁碟陣列（software raid）， 這些技術可以將一個分割槽格式化為多個檔案系統（例如LVM），也能夠將多個分割槽合成一個檔案系統（LVM, RAID）！ 所以說，目前我們在格式化時已經不再說成針對 partition 來格式化了， 通常我們可以稱呼一個可被掛載的資料為一個檔案系統而不是一個分割槽喔！

那麼檔案系統是如何執行的呢？這與作業系統的檔案資料有關。較新的作業系統的檔案資料除了檔案實際內容外， 通常含有非常多的屬性，例如 Linux 作業系統的檔案許可權（rwx）與檔案屬性（擁有者、群組、時間引數等）。 檔案系統通常會將這兩部份的資料分別存放在不同的區塊，許可權與屬性放置到 inode 中，至於實際資料則放置到 data block 區塊中。 另外，還有一個超級區塊 （superblock） 會記錄整個檔案系統的整體資訊，包括 inode 與 block 的總量、使用量、剩餘量等。

每個 inode 與 block 都有編號，至於這三個資料的意義可以簡略說明如下：

superblock：記錄此 filesystem 的整體資訊，包括inode/block的總量、使用量、剩餘量，以及檔案系統的格式與相關資訊等；

inode：記錄檔案的屬性，一個檔案佔用一個inode，同時記錄此檔案的資料所在的 block號碼；

block：實際記錄檔案的內容，若檔案太大時，會佔用多個 block 。

由於每個 inode 與 block 都有編號，而每個檔案都會佔用一個 inode ，inode 內則有檔案資料放置的 block 號碼。 因此，我們可以知道的是，如果能夠找到檔案的 inode 的話，那麼自然就會知道這個檔案所放置資料的 block 號碼， 當然也就能夠讀出該檔案的實際資料了。這是個比較有效率的作法，因為如此一來我們的磁碟就能夠在短時間內讀取出全部的資料， 讀寫的效能比較好囉。

我們將 inode 與 block 區塊用圖解來說明一下，如下圖所示，檔案系統先格式化出 inode 與block 的區塊，假設某一個檔案的屬性與許可權資料是放置到 inode 4 號（下圖較小方格內），而這個 inode 記錄了檔案資料的實際放置點為 2, 7, 13, 15 這四個 block 號碼，此時我們的作業系統就能夠據此來排列磁碟的讀取順序，可以一口氣將四個 block 內容讀出來！ 那麼資料的讀取就如同下圖中的箭頭所指定的模樣了。

上圖中我們假設檔案的資料依序寫入1->7->4->15號這四個 block 號碼中， 但這個檔案系統沒有辦法一口氣就知道四個 block 的號碼，他得要一個一個的將 block 讀出後，才會知道下一個block 在何處。 如果同一個檔案資料寫入的 block 分散的太過厲害時，則我們的磁頭將無法在磁碟轉一圈就讀到所有的資料， 因此磁碟就會多轉好幾圈才能完整的讀取到這個檔案的內容！

常常會聽到所謂的“磁碟重組”吧？ 需要磁碟重組的原因就是檔案寫入的 block 太過於離散了，此時檔案讀取的效能將會變的很差所致。 這個時候可以通過磁碟重組將同一個檔案所屬的blocks 彙整在一起，這樣資料的讀取會比較容易啊！ 想當然爾，FAT 的檔案系統需要三不五時的磁碟重組一下，那麼 Ext2 是否需要磁碟重整呢？

由於 Ext2 是索引式檔案系統，基本上不太需要常常進行磁碟重組的。但是如果檔案系統使用太久， 常常刪除/編輯/新增檔案時，那麼還是可能會造成檔案資料太過於離散的問題，此時或許會需要進行重整一下的。 不過，老實說，倒是沒有在 Linux 作業系統上面進行過Ext2/Ext3 檔案系統的磁碟重組說！似乎不太需要啦！^_^

3，Linux 的 EXT2 檔案系統（inode）

Linux 的檔案除了原有的資料內容外，還含有非常多的許可權與屬性，這些許可權與屬性是為了保護每個使用者所擁有資料的隱密性。 而前一小節我們知道filesystem 裡面可能含有的 inode/block/superblock 等。為什麼要談這個呢？因為標準的Linux 檔案系統 Ext2 就是使用這種 inode 為基礎的檔案系統啦！

而如同前一小節所說的，inode 的內容在記錄檔案的許可權與相關屬性，至於 block 區塊則是在記錄檔案的實際內容。 而且檔案系統一開始就將 inode 與 block 規劃好了，除非重新格式化（或者利用 resize2fs 等指令變更檔案系統大小），否則 inode 與 block 固定後就不再變動。但是如果仔細考慮一下，如果我的檔案系統高達數百GB時， 那麼將所有的 inode 與 block 通通放置在一起將是很不智的決定，因為 inode 與 block 的數量太龐大，不容易管理。

為此之故，因此 Ext2 檔案系統在格式化的時候基本上是區分為多個區塊群組 （blockgroup） 的，每個區塊群組都有獨立的 inode/block/superblock 系統。感覺上就好像我們在當兵時，一個營裡面有分成數個連，每個連有自己的聯絡系統， 但最終都向營部回報連上最正確的資訊一般！這樣分成一群群的比較好管理啦！整個來說，Ext2 格式化後有點像下面這樣：

在整體的規劃當中，檔案系統最前面有一個開機扇區（boot sector），這個開機扇區可以安裝開機管理程式， 這是個非常重要的設計，因為如此一來我們就能夠將不同的開機管理程式安裝到個別的檔案系統最前端，而不用覆蓋整顆磁碟唯一的 MBR， 這樣也才能夠製作出多重開機的環境啊！至於每一個區塊群組（block group）的六個主要內容說明如後：

data block （資料區塊）

data block 是用來放置檔案內容資料地方，在 Ext2 檔案系統中所支援的 block 大小有 1K, 2K及 4K 三種而已。在格式化時 block 的大小就固定了，且每個 block 都有編號，以方便 inode的記錄啦。 不過要注意的是，由於 block 大小的差異，會導致該檔案系統能夠支援的最大磁碟容量與最大單一檔案大小並不相同。 因為 block 大小而產生的 Ext2 檔案系統限制如下：

Block大小	1Kb	2Kb	4Kb
最大單一檔案限制	16GB	256GB	2TB
最大檔案系統總容量	2TB	8TB	16TB

你需要注意的是，雖然 Ext2 已經能夠支援大於 2GB 以上的單一檔案大小，不過某些應用程式依然使用舊的限制， 也就是說，某些程式只能夠捉到小於 2GB 以下的檔案而已，這就跟檔案系統無關了！ 舉例來說，在環工方面的應用中有一套秀圖軟體稱為PAVE， 這套軟體就無法捉到在數值模式模擬後產生的大於 2GB 以上的檔案！所以後來只能找更新的軟體來取代它了！

除此之外 Ext2 檔案系統的 block 還有什麼限制呢？有的！基本限制如下：

（1）原則上，block 的大小與數量在格式化完就不能夠再改變了（除非重新格式化）；

（2）每個 block 內最多隻能夠放置一個檔案的資料；

（3）承上，如果檔案大於 block 的大小，則一個檔案會佔用多個 block 數量；

（4）承上，若檔案小於 block ，則該 block 的剩餘容量就不能夠再被使用了（磁碟空間會浪費）

如上第四點所說，由於每個 block 僅能容納一個檔案的資料而已，因此如果你的檔案都非常小，但是你的 block 在格式化時卻選用最大的 4K 時，可能會產生一些容量的浪費喔！我們以下面的一個簡單例題來算一下空間的浪費吧！

例題：假設你的Ext2檔案系統使用 4K block ，而該檔案系統中有 10000 個小檔案，每個檔案大小均為 50Bytes， 請問此時你的磁碟浪費多少容量？答：由於 Ext2 檔案系統中一個 block僅能容納一個檔案，因此每個 block 會浪費“ 4096 - 50 = 4046 （Byte）”， 系統中總共有一萬個小檔案，所有檔案大小為：50 （Bytes） x 10000 = 488.3KBytes，但此時浪費的容量為：“ 4046 （Bytes） x 10000 = 38.6MBytes ”。想一想，不到 1MB 的總檔案大小卻浪費將近 40MB 的容量，且檔案越多將造成越多的磁碟容量浪費。

什麼情況會產生上述的狀況呢？例如 BBS 網站的資料啦！如果 BBS 上面的資料使用的是純文字來記載每篇留言， 而留言內容如果都寫上“如題”時，想一想，是否就會產生很多小檔案了呢？

好，既然大的 block 可能會產生較嚴重的磁碟容量浪費，那麼我們是否就將 block 大小訂為1K 即可？ 這也不妥，因為如果 block 較小的話，那麼大型檔案將會佔用數量更多的 block ，而 inode 也要記錄更多的 block 號碼，此時將可能導致檔案系統不良的讀寫效能。

所以我們可以說，在您進行檔案系統的格式化之前，請先想好該檔案系統預計使用的情況。以鳥哥來說，我的數值模式模擬平臺隨便一個檔案都好幾百 MB，那麼 block 容量當然選擇較大的！至少檔案系統就不必記錄太多的 block 號碼，讀寫起來也比較方便啊！

Tips 事實上，現在的磁碟容量都太大了！所以，大概大家都只會選擇 4K 的 block 大小吧！呵呵！

inode table （inode 表格）

再來討論一下 inode 這個玩意兒吧！如前所述 inode 的內容在記錄檔案的屬性以及該檔案實際資料是放置在哪幾號 block 內！ 基本上，inode 記錄的檔案資料至少有下面這些：

該檔案的存取模式（read/write/excute）；

該檔案的擁有者與群組（owner/group）；

該檔案的容量；

該檔案建立或狀態改變的時間（ctime）；

最近一次的讀取時間（atime）；

最近修改的時間（mtime）；

定義檔案特性的旗標（flag），如 SetUID...；

該檔案真正內容的指向 （pointer）；

 

inode 的數量與大小也是在格式化時就已經固定了，除此之外 inode 還有些什麼特色呢？

每個 inode 大小均固定為 128 Bytes （新的 ext4 與 xfs 可設定到 256 Bytes）；

每個檔案都僅會佔用一個 inode 而已；

承上，因此檔案系統能夠建立的檔案數量與 inode 的數量有關；

系統讀取檔案時需要先找到 inode，並分析 inode 所記錄的許可權與使用者是否符合，若符合才能夠開始實際讀取 block 的內容。

我們約略來分析一下 EXT2 的 inode / block 與檔案大小的關係好了。inode 要記錄的資料非常多，但偏偏又只有 128Bytes 而已， 而 inode 記錄一個 block 號碼要花掉 4Byte ，假設我一個檔案有 400MB 且每個 block 為 4K 時， 那麼至少也要十萬筆 block 號碼的記錄呢！inode 哪有這麼多可記錄的資訊？為此我們的系統很聰明的將 inode 記錄 block 號碼的區域定義為12個直接，一個間接, 一個雙間接與一個三間接記錄區。這是啥？我們將 inode 的結構畫一下好了。

上圖最左邊為 inode 本身 （128 Bytes），裡面有 12 個直接指向 block 號碼的對照，這 12筆記錄就能夠直接取得 block 號碼啦！ 至於所謂的間接就是再拿一個 block 來當作記錄 block號碼的記錄區，如果檔案太大時， 就會使用間接的 block 來記錄號碼。如上圖 7.1.4 當中間接只是拿一個 block 來記錄額外的號碼而已。 同理，如果檔案持續長大，那麼就會利用所謂的雙間接，第一個 block 僅再指出下一個記錄號碼的 block 在哪裡， 實際記錄的在第二個block 當中。依此類推，三間接就是利用第三層 block 來記錄號碼啦！

這樣子 inode 能夠指定多少個 block 呢？我們以較小的 1K block 來說明好了，可以指定的情況如下：

12 個直接指向： 12*1K=12K 由於是直接指向，所以總共可記錄 12 筆記錄，因此總額大小為如上所示；

間接： 256*1K=256K 每筆 block 號碼的記錄會花去 4Bytes，因此 1K 的大小能夠記錄256 筆記錄，因此一個間接可以記錄的檔案大小如上；

雙間接： 2562561K=2562K 第一層 block 會指定 256 個第二層，每個第二層可以指定256 個號碼，因此總額大小如上；

三間接： 256256256*1K=2563K 第一層 block 會指定 256 個第二層，每個第二層可以指定 256 個第三層，每個第三層可以指定 256 個號碼，因此總額大小如上；

總額：將直接、間接、雙間接、三間接加總，得到 12 + 256 + 256256 + 256256*256（K） = 16GB。

 

此時我們知道當檔案系統將 block 格式化為 1K 大小時，能夠容納的最大檔案為 16GB，比較一下檔案系統限制表的結果可發現是一致的！但這個方法不能用在 2K 及 4K block 大小的計算中， 因為大於 2K 的 block 將會受到 Ext2 檔案系統本身的限制，所以計算的結果會不太符合之故。

Tips 如果你的 Linux 依舊使用 Ext2/Ext3/Ext4 檔案系統的話，例如鳥哥之前的 CentOS 6.x系統，那麼預設還是使用 Ext4 的檔案系統喔！ Ext4 檔案系統的 inode 容量已經可以擴大到256Bytes 了，更大的 inode 容量，可以紀錄更多的檔案系統資訊，包括新的 ACL 以及SELinux 型別等， 當然，可以紀錄的單一檔案大小達 16TB 且單一檔案系統總容量可達 1EB哩！

Superblock （超級區塊）

Superblock 是記錄整個 filesystem 相關資訊的地方， 沒有 Superblock ，就沒有這個filesystem 了。他記錄的資訊主要有：

block 與 inode 的總量；

未使用與已使用的 inode / block 數量；

block 與 inode 的大小 （block 為 1, 2, 4K，inode 為 128Bytes 或 256Bytes）；

filesystem 的掛載時間、最近一次寫入資料的時間、最近一次檢驗磁碟 （fsck） 的時間等檔案系統的相關資訊；

一個 valid bit 數值，若此檔案系統已被掛載，則 valid bit 為 0 ，若未被掛載，則 valid bit為 1 。

 

Superblock 是非常重要的，因為我們這個檔案系統的基本資訊都寫在這裡，因此，如果superblock 死掉了， 你的檔案系統可能就需要花費很多時間去挽救啦！一般來說，superblock 的大小為 1024Bytes。相關的 superblock 訊息我們等一下會以 dumpe2fs 指令來調用出來觀察喔！

此外，每個 block group 都可能含有 superblock 喔！但是我們也說一個檔案系統應該僅有一個 superblock 而已，那是怎麼回事啊？ 事實上除了第一個 block group 內會含有 superblock之外，後續的 block group 不一定含有 superblock ， 而若含有 superblock 則該 superblock主要是做為第一個 block group 內 superblock 的備份咯，這樣可以進行 superblock 的救援呢！

Filesystem Description （檔案系統描述說明）

這個區段可以描述每個 block group 的開始與結束的 block 號碼，以及說明每個區段（superblock, bitmap, inodemap, data block） 分別介於哪一個 block 號碼之間。這部份也能夠用 dumpe2fs 來觀察的。

 

block bitmap （區塊對照表）

如果你想要新增檔案時總會用到 block 吧！那你要使用哪個 block 來記錄呢？當然是選擇“空的 block ”來記錄新檔案的資料囉。 那你怎麼知道哪個 block 是空的？這就得要通過 blockbitmap 的輔助了。從 block bitmap 當中可以知道哪些 block 是空的，因此我們的系統就能夠很快速的找到可使用的空間來處置檔案囉。

同樣的，如果你刪除某些檔案時，那麼那些檔案原本佔用的 block 號碼就得要釋放出來， 此時在 block bitmap 當中相對應到該 block 號碼的標誌就得要修改成為“未使用中”囉！這就是bitmap 的功能。

inode bitmap （inode 對照表）

這個其實與 block bitmap 是類似的功能，只是 block bitmap 記錄的是使用與未使用的 block號碼， 至於 inode bitmap 則是記錄使用與未使用的 inode 號碼囉！

dumpe2fs： 查詢 Ext 家族 superblock 資訊的指令

瞭解了檔案系統的概念之後，再來當然是觀察這個檔案系統囉！剛剛談到的各部分資料都與block 號碼有關！ 每個區段與 superblock 的資訊都可以使用 dumpe2fs 這個指令來查詢的！不過很可惜的是，我們的 CentOS 7 現在是以 xfs 為預設檔案系統， 所以目前你的系統應該無法使用 dumpe2fs 去查詢任何檔案系統的。沒關係，鳥哥先找自己的一部機器來跟大家介紹， 你可以在後續的格式化內容講完之後，自己切出一個 ext4 的檔案系統去查詢看看即可。鳥哥這塊檔案系統是 1GB 的容量，使用預設方式來進行格式化的， 觀察的內容如下：

 

# dumpe2fs [-bh] 裝置檔名

選項與引數：

-b ：列出保留為壞軌的部分（一般用不到吧！？）

-h ：僅列出 superblock 的資料，不會列出其他的區段內容！

範例：一塊 1GB ext4 檔案系統內容

[[email protected] ~]# blkid <==這個指令可以叫出目前系統有被格式化的裝置

/dev/vda1: LABEL="myboot" UUID="ce4dbf1b-2b3d-4973-8234-73768e8fd659" TYPE="xfs"

/dev/vda2: LABEL="myroot" UUID="21ad8b9a-aaad-443c-b732-4e2522e95e23" TYPE="xfs"

/dev/vda3: UUID="12y99K-bv2A-y7RY-jhEW-rIWf-PcH5-SaiApN" TYPE="LVM2_member"

/dev/vda5: UUID="e20d65d9-20d4-472f-9f91-cdcfb30219d6" TYPE="ext4" <==看到 ext4 了！

[[email protected] ~]# dumpe2fs /dev/vda5

dumpe2fs 1.42.9 （28-Dec-2013）

Filesystem volume name: <none> # 檔案系統的名稱（不一定會有）

Last mounted on: <not available> # 上一次掛載的目錄位置

Filesystem UUID: e20d65d9-20d4-472f-9f91-cdcfb30219d6

Filesystem magic number: 0xEF53 # 上方的 UUID 為 Linux 對裝置的定義碼

Filesystem revision #: 1 （dynamic） # 下方的 features 為檔案系統的特徵資料

Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit

flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Filesystem flags: signed_directory_hash

Default mount options: user_xattr acl # 預設在掛載時會主動加上的掛載引數

Filesystem state: clean # 這塊檔案系統的狀態為何，clean 是沒問題

Errors behavior: Continue

Filesystem OS type: Linux

Inode count: 65536 # inode 的總數

Block count: 262144 # block 的總數

Reserved block count: 13107 # 保留的 block 總數

Free blocks: 249189 # 還有多少的 block 可用數量

Free inodes: 65525 # 還有多少的 inode 可用數量

First block: 0

Block size: 4096 # 單個 block 的容量大小

Fragment size: 4096

Group descriptor size: 64

....（中間省略）....

Inode size: 256 # inode 的容量大小！已經是 256 了喔！

....（中間省略）....

Journal inode: 8

Default directory hash: half_md4

Directory Hash Seed: 3c2568b4-1a7e-44cf-95a2-c8867fb19fbc

Journal backup: inode blocks

Journal features: （none）

Journal size: 32M # Journal 日誌式資料的可供紀錄總容量

Journal length: 8192

Journal sequence: 0x00000001

Journal start: 0

Group 0: （Blocks 0-32767） # 第一塊 block group 位置

Checksum 0x13be, unused inodes 8181

Primary superblock at 0, Group descriptors at 1-1 # 主要 superblock 的所在喔！

Reserved GDT blocks at 2-128

Block bitmap at 129 （+129）, Inode bitmap at 145 （+145）

Inode table at 161-672 （+161） # inode table 的所在喔！

28521 free blocks, 8181 free inodes, 2 directories, 8181 unused inodes

Free blocks: 142-144, 153-160, 4258-32767 # 下面兩行說明剩餘的容量有多少

Free inodes: 12-8192

Group 1: （Blocks 32768-65535） [INODE_UNINIT] # 後續為更多其他的 block group 喔！

....（下面省略）....

# 由於資料量非常的龐大，因此鳥哥將一些資訊省略輸出了！上表與你的螢幕會有點差異。

# 前半部在秀出 supberblock 的內容，包括標頭名稱（Label）以及inode/block的相關資訊

# 後面則是每個 block group 的個別資訊了！您可以看到各區段資料所在的號碼！

# 也就是說，基本上所有的資料還是與 block 的號碼有關就是了！很重要！

 

如上所示，利用 dumpe2fs 可以查詢到非常多的資訊，不過依內容主要可以區分為上半部是superblock 內容， 下半部則是每個 block group 的資訊了。從上面的表格中我們可以觀察到這個 /dev/vda5 規劃的 block 為 4K， 第一個 block 號碼為 0 號，且 block group 內的所有資訊都以 block 的號碼來表示的。 然後在 superblock 中還有談到目前這個檔案系統的可用block 與 inode 數量喔！

至於 block group 的內容我們單純看 Group0 資訊好了。從上表中我們可以發現：

Group0 所佔用的 block 號碼由 0 到 32767 號，superblock 則在第 0 號的 block 區塊內！

檔案系統描述說明在第 1 號 block 中；

block bitmap 與 inode bitmap 則在 129 及 145 的 block 號碼上。

至於 inode table 分佈於 161-672 的 block 號碼中！

由於 （1）一個 inode 佔用 256 Bytes ，（2）總共有 672 - 161 + 1（161本身） = 512個 block 花在 inode table 上， （3）每個 block 的大小為 4096 Bytes（4K）。由這些資料可以算出 inode 的數量共有 512 * 4096 / 256 = 8192 個 inode 啦！

這個 Group0 目前可用的 block 有 28521 個，可用的 inode 有 8181 個；

剩餘的 inode 號碼為 12 號到 8192 號。

 

 

4，與目錄樹的關係

由前一小節的介紹我們知道在 Linux 系統下，每個檔案（不管是一般檔案還是目錄檔案）都會佔用一個 inode ， 且可依據檔案內容的大小來分配多個 block 給該檔案使用。而由第五章的許可權說明中我們知道目錄的內容在記錄檔名， 一般檔案才是實際記錄資料內容的地方。那麼目錄與檔案在檔案系統當中是如何記錄資料的呢？基本上可以這樣說：

目錄

當我們在 Linux 下的檔案系統建立一個目錄時，檔案系統會分配一個 inode 與至少一塊 block給該目錄。其中，inode 記錄該目錄的相關許可權與屬性，並可記錄分配到的那塊 block 號碼；而 block 則是記錄在這個目錄下的檔名與該檔名佔用的 inode 號碼資料。也就是說目錄所佔用的 block 內容在記錄如下的資訊：

如果想要實際觀察 root 主資料夾內的檔案所佔用的 inode 號碼時，可以使用 ls -i 這個選項來處理：

# ls -li

total 8

53735697 -rw-------. 1 root root 1816 May 4 17:57 anaconda-ks.cfg

53745858 -rw-r--r--. 1 root root 1864 May 4 18:01 initial-setup-ks.cfg

由於每個人所使用的計算機並不相同，系統安裝時選擇的專案與 partition 都不一樣，因此你的環境不可能與我的 inode 號碼一模一樣！上表的左邊所列出的 inode 僅是系統所顯示的結果而已！而由這個目錄的 block 結果我們現在就能夠知道， 當你使用“ ll / ”時，出現的目錄幾乎都是 1024 的倍數，為什麼呢？因為每個 block 的數量都是 1K, 2K, 4K 嘛！ 看一下環境：

# ll -d / /boot /usr/sbin /proc /sys

dr-xr-xr-x. 17 root root 4096 May 4 17:56 / <== 1 個 4K block

dr-xr-xr-x. 4 root root 4096 May 4 17:59 /boot <== 1 個 4K block

dr-xr-xr-x. 155 root root 0 Jun 15 15:43 /proc <== 這兩個為記憶體內資料，不佔磁碟容量

dr-xr-xr-x. 13 root root 0 Jun 15 23:43 /sys

dr-xr-xr-x. 2 root root 16384 May 4 17:55 /usr/sbin <== 4 個 4K block

由於根目錄使用的 block 大小為 4K ，因此每個目錄幾乎都是 4K 的倍數。 其中由於/usr/sbin 的內容比較複雜因此佔用了 4 個 block ！至於奇怪的 /proc 我們之前就講過該目錄不佔磁碟容量， 所以當然耗用的 block 就是 0 囉！

 

檔案

當我們在 Linux 下的 ext2 建立一個一般檔案時， ext2 會分配一個 inode 與相對於該檔案大小的 block 數量給該檔案。例如：假設我的一個 block 為 4 KBytes ，而我要建立一個 100KBytes 的檔案，那麼 linux 將分配一個 inode 與 25 個 block 來儲存該檔案！ 但同時請注意，由於 inode 僅有 12 個直接指向，因此還要多一個 block 來作為區塊號碼的記錄喔！

 

目錄樹讀取

好了，經過上面的說明你也應該要很清楚的知道 inode 本身並不記錄檔名，檔名的記錄是在目錄的 block 當中。 因此在檔案與目錄的許可權說明中， 我們才會提到“新增/刪除/更名檔名與目錄的 w 許可權有關”的特色！那麼因為檔名是記錄在目錄的 block 當中， 因此當我們要讀取某個檔案時，就務必會經過目錄的 inode 與 block ，然後才能夠找到那個待讀取檔案的 inode 號碼， 最終才會讀到正確的檔案的 block 內的資料。

由於目錄樹是由根目錄開始讀起，因此係統通過掛載的資訊可以找到掛載點的 inode 號碼，此時就能夠得到根目錄的 inode 內容，並依據該 inode 讀取根目錄的 block 內的檔名資料，再一層一層的往下讀到正確的檔名。舉例來說，如果我想要讀取 /etc/passwd 這個檔案時，系統是如何讀取的呢？

# ll -di / /etc /etc/passwd

128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 /

33595521 drwxr-xr-x. 131 root root 8192 Jun 17 00:20 /etc

36628004 -rw-r--r--. 1 root root 2092 Jun 17 00:20 /etc/passwd

 

在系統上面與 /etc/passwd 有關的目錄與檔案資料如上表所示，該檔案的讀取流程為（假設讀取者身份為 dmtsai 這個一般身份使用者）：

1. / 的 inode： 通過掛載點的資訊找到 inode 號碼為 128 的根目錄 inode，且 inode 規範的許可權讓我們可以讀取該 block 的內容（有 r 與 x）；

2. / 的 block： 經過上個步驟取得 block 的號碼，並找到該內容有 etc/ 目錄的 inode 號碼（33595521）；

3. etc/ 的 inode： 讀取 33595521 號 inode 得知 dmtsai 具有 r 與 x 的許可權，因此可以讀取etc/ 的 block 內容；

4. etc/ 的 block： 經過上個步驟取得 block 號碼，並找到該內容有 passwd 檔案的 inode 號碼 （36628004）；

5. passwd 的 inode： 讀取 36628004 號 inode 得知 dmtsai 具有 r 的許可權，因此可以讀取passwd 的 block 內容；

6. passwd 的 block： 最後將該 block 內容的資料讀出來。

7. filesystem 大小與磁碟讀取效能：

 

另外，關於檔案系統的使用效率上，當你的一個檔案系統規劃的很大時，例如 100GB 這麼大時， 由於磁碟上面的資料總是來來去去的，所以，整個檔案系統上面的檔案通常無法連續寫在一起（block 號碼不會連續的意思）， 而是填入式的將資料填入沒有被使用的 block 當中。如果檔案寫入的 block 真的分的很散， 此時就會有所謂的檔案資料離散的問題發生了。

如前所述，雖然我們的 ext2 在 inode 處已經將該檔案所記錄的 block 號碼都記上了， 所以資料可以一次性讀取，但是如果檔案真的太過離散，確實還是會發生讀取效率低落的問題。 因為磁頭還是得要在整個檔案系統中來來去去的頻繁讀取！ 果真如此，那麼可以將整個filesystme 內的資料全部複製出來，將該 filesystem 重新格式化， 再將資料給他複製回去即可解決這個問題。

此外，如果 filesystem 真的太大了，那麼當一個檔案分別記錄在這個檔案系統的最前面與最後面的 block 號碼中， 此時會造成磁碟的機械手臂移動幅度過大，也會造成資料讀取效能的低落。而且磁頭在搜尋整個 filesystem 時， 也會花費比較多的時間去搜尋！因此， partition的規劃並不是越大越好， 而是真的要針對您的主機用途來進行規劃才行！^_^

 

5,EXT2/EXT3/EXT4 檔案的存取與日誌式檔案系統的功能

上一小節談到的僅是讀取而已，那麼如果是新建一個檔案或目錄時，我們的檔案系統是如何處理的呢？ 這個時候就得要 block bitmap 及 inode bitmap 的幫忙了！假設我們想要新增一個檔案，此時檔案系統的行為是：

1. 先確定使用者對於欲新增檔案的目錄是否具有 w 與 x 的許可權，若有的話才能新增；

2. 根據 inode bitmap 找到沒有使用的 inode 號碼，並將新檔案的許可權/屬性寫入；

3. 根據 block bitmap 找到沒有使用中的 block 號碼，並將實際的資料寫入 block 中，且更新 inode 的 block 指向資料；

4. 將剛剛寫入的 inode 與 block 資料同步更新 inode bitmap 與 block bitmap，並更新superblock 的內容。

一般來說，我們將 inode table 與 data block 稱為資料存放區域，至於其他例如 superblock、block bitmap 與 inode bitmap 等區段就被稱為 metadata （中介資料） 囉，因為 superblock,inode bitmap 及 block bitmap 的資料是經常變動的，每次新增、移除、編輯時都可能會影響到這三個部分的資料，因此才被稱為中介資料的啦。

資料的不一致 （Inconsistent） 狀態

在一般正常的情況下，上述的新增動作當然可以順利的完成。但是如果有個萬一怎麼辦？ 例如你的檔案在寫入檔案系統時，因為不知名原因導致系統中斷（例如突然的停電啊、 系統核心發生錯誤啊～等等的怪事發生時），所以寫入的資料僅有 inode table 及 data block 而已，最後一個同步更新中介資料的步驟並沒有做完，此時就會發生 metadata 的內容與實際資料存放區產生不一致 （Inconsistent） 的情況了。

既然有不一致當然就得要克服！在早期的 Ext2 檔案系統中，如果發生這個問題， 那麼系統在重新開機的時候，就會藉由 Superblock 當中記錄的 valid bit （是否有掛載） 與 filesystemstate （clean 與否） 等狀態來判斷是否強制進行資料一致性的檢查！若有需要檢查時則以e2fsck 這支程式來進行的。

不過，這樣的檢查真的是很費時～因為要針對 metadata 區域與實際資料存放區來進行比對，呵呵～得要搜尋整個 filesystem 呢～如果你的檔案系統有 100GB 以上，而且裡面的檔案數量又多時， 哇！系統真忙碌～而且在對 Internet 提供服務的伺服器主機上面， 這樣的檢查真的會造成主機復原時間的拉長～真是麻煩～這也就造成後來所謂日誌式檔案系統的興起了。

日誌式檔案系統 （Journaling filesystem）

為了避免上述提到的檔案系統不一致的情況發生，因此我們的前輩們想到一個方式， 如果在我們的 filesystem 當中規劃出一個區塊，該區塊專門在記錄寫入或修訂檔案時的步驟， 那不就可以簡化一致性檢查的步驟了？也就是說：

1. 預備：當系統要寫入一個檔案時，會先在日誌記錄區塊中紀錄某個檔案準備要寫入的資訊；

2. 實際寫入：開始寫入檔案的許可權與資料；開始更新 metadata 的資料；

3. 結束：完成資料與 metadata 的更新後，在日誌記錄區塊當中完成該檔案的紀錄。

在這樣的程式當中，萬一資料的紀錄過程當中發生了問題，那麼我們的系統只要去檢查日誌記錄區塊， 就可以知道哪個檔案發生了問題，針對該問題來做一致性的檢查即可，而不必針對整塊 filesystem 去檢查， 這樣就可以達到快速修復 filesystem 的能力了！這就是日誌式檔案最基礎的功能囉～

那麼我們的 ext2 可達到這樣的功能嗎？當然可以啊！ 就通過 ext3/ext4 即可！ ext3/ext4 是ext2 的升級版本，並且可向下相容 ext2 版本呢！ 所以囉，目前我們才建議大家，可以直接使用 ext4 這個 filesystem 啊！ 如果你還記得 dumpe2fs 輸出的訊息，可以發現 superblock 裡面含有下面這樣的資訊：

Journal inode: 8

Journal backup: inode blocks

Journal features: （none）

Journal size: 32M

Journal length: 8192

Journal sequence: 0x00000001

看到了吧！通過 inode 8 號記錄 journal 區塊的 block 指向，而且具有 32MB 的容量在處理日誌呢！ 這樣對於所謂的日誌式檔案系統有沒有比較有概念一點呢？^_^。

 

6,Linux 檔案系統的執行

我們現在知道了目錄樹與檔案系統的關係了， 所有的資料都得要載入到記憶體後 CPU 才能夠對該資料進行處理。想一想，如果你常常編輯一個好大的檔案， 在編輯的過程中又頻繁的要系統來寫入到磁碟中，由於磁碟寫入的速度要比記憶體慢很多， 因此你會常常耗在等待磁碟的寫入/讀取上。真沒效率！

為了解決這個效率的問題，因此我們的 Linux 使用的方式是通過一個稱為非同步處理（asynchronously） 的方式。所謂的非同步處理是這樣的：

當系統載入一個檔案到記憶體後，如果該檔案沒有被更動過，則在記憶體區段的檔案資料會被設定為乾淨（clean）的。 但如果記憶體中的檔案資料被更改過了（例如你用 nano 去編輯過這個檔案），此時該記憶體中的資料會被設定為髒的 （Dirty）。此時所有的動作都還在記憶體中執行，並沒有寫入到磁碟中！ 系統會不定時的將記憶體中設定為“Dirty”的資料寫回磁碟，以保持磁碟與記憶體資料的一致性。 你也可以利用第四章談到的 sync指令來手動強迫寫入磁碟。

我們知道記憶體的速度要比磁碟快的多，因此如果能夠將常用的檔案放置到記憶體當中，這不就會增加系統性能嗎？ 沒錯！是有這樣的想法！因此我們 Linux 系統上面檔案系統與記憶體有非常大的關係喔：

系統會將常用的檔案資料放置到記憶體的緩衝區，以加速檔案系統的讀/寫；

承上，因此 Linux 的實體記憶體最後都會被用光！這是正常的情況！可加速系統性能；

你可以手動使用 sync 來強迫記憶體中設定為 Dirty 的檔案回寫到磁碟中；

若正常關機時，關機指令會主動呼叫 sync 來將記憶體的資料回寫入磁碟內；

但若不正常關機（如跳電、宕機或其他不明原因），由於資料尚未回寫到磁碟內， 因此重新開機後可能會花很多時間在進行磁碟檢驗，甚至可能導致檔案系統的損毀（非磁碟損毀）。

7，掛載點的意義 （mount point）

每個 filesystem 都有獨立的 inode / block / superblock 等資訊，這個檔案系統要能夠連結到目錄樹才能被我們使用。 將檔案系統與目錄樹結合的動作我們稱為“掛載”。 關於掛載的一些特性我們在第二章稍微提過， 重點是：掛載點一定是目錄，該目錄為進入該檔案系統的入口。因此並不是你有任何檔案系統都能使用，必須要“掛載”到目錄樹的某個目錄後，才能夠使用該檔案系統的。

舉例來說，如果你是依據之前的方法安裝你的 CentOS 7.x 的話， 那麼應該會有三個掛載點才是，分別是 /, /boot, /home 三個 （系統上對應的裝置檔名為 LVM, LVM,/dev/vda2）。 那如果觀察這三個目錄的 inode 號碼時，我們可以發現如下的情況：

[[email protected] ~]# ls -lid / /boot /home

128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 /

128 dr-xr-xr-x. 4 root root 4096 May 4 17:59 /boot

128 drwxr-xr-x. 5 root root 41 Jun 17 00:20 /home

看到了吧！由於 XFS filesystem 最頂層的目錄之 inode 一般為 128 號，因此可以發現 /,/boot, /home 為三個不同的 filesystem 囉！ （因為每一行的檔案屬性並不相同，且三個目錄的掛載點也均不相同之故。） 我們在第六章一開始的路徑中曾經提到根目錄下的 . 與 .. 是相同的東西， 因為許可權是一模一樣嘛！如果使用檔案系統的觀點來看，同一個 filesystem 的某個 inode 只會對應到一個檔案內容而已（因為一個檔案佔用一個 inode 之故）， 因此我們可以通過判斷 inode 號碼來確認不同檔名是否為相同的檔案喔！所以可以這樣看：

[[email protected] ~]# ls -ild / /. /..

128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 /

128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 /.

128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 /..

上面的資訊中由於掛載點均為 / ，因此三個檔案 （/, /., /..） 均在同一個 filesystem 內，而這三個檔案的 inode 號碼均為 128 號，因此這三個檔名都指向同一個 inode 號碼，當然這三個檔案的內容也就完全一模一樣了！ 也就是說，根目錄的上層 （/..） 就是他自己！這麼說，看的懂了嗎？ ^^

8，其他 Linux 支援的檔案系統與 VFS

 

雖然 Linux 的標準檔案系統是 ext2 ，且還有增加了日誌功能的 ext3/ext4 ，事實上，Linux 還有支援很多檔案系統格式的， 尤其是最近這幾年推出了好幾種速度很快的日誌式檔案系統，包括 SGI 的 XFS 檔案系統， 可以適用更小型檔案的 Reiserfs 檔案系統，以及 Windows 的FAT 檔案系統等等， 都能夠被 Linux 所支援喔！常見的支援檔案系統有：

傳統檔案系統：ext2 / minix / MS-DOS / FAT （用 vfat 模組） / iso9660 （光碟）等等；

日誌式檔案系統： ext3 /ext4 / ReiserFS / Windows' NTFS / IBM's JFS / SGI's XFS /ZFS

網路檔案系統： NFS / SMBFS

想要知道你的 Linux 支援的檔案系統有哪些，可以察看下面這個目錄：

[[email protected] ~]# ls -l /lib/modules/$（uname -r）/kernel/fs

比如我的：ls -l /lib/modules/3.10.0-693.el7.x86_64/kernel/fs/

 

系統目前已載入到記憶體中支援的檔案系統則有：

[[email protected] ~]# cat /proc/filesystems

 

Linux VFS （Virtual Filesystem Switch）

瞭解了我們使用的檔案系統之後，再來則是要提到，那麼 Linux 的核心又是如何管理這些認識的檔案系統呢？ 其實，整個 Linux 的系統都是通過一個名為 Virtual Filesystem Switch 的核心功能去讀取 filesystem 的。 也就是說，整個 Linux 認識的 filesystem 其實都是 VFS 在進行管理，我們使用者並不需要知道每個 partition 上頭的 filesystem 是什麼～ VFS 會主動的幫我們做好讀取的動作呢～

假設你的 / 使用的是 /dev/hda1 ，用 ext3 ，而 /home 使用 /dev/hda2 ，用 reiserfs ， 那麼你取用 /home/dmtsai/.bashrc 時，有特別指定要用的什麼檔案系統的模組來讀取嗎？ 應該是沒有吧！這個就是 VFS 的功能啦！通過這個 VFS 的功能來管理所有的 filesystem， 省去我們需要自行設定讀取檔案系統的定義啊～方便很多！

 

9，XFS 檔案系統簡介

CentOS 7 開始，預設的檔案系統已經由原本的 EXT4 變成了 XFS 檔案系統了！為啥CentOS 要捨棄對 Linux 支援度最完整的 EXT 家族而改用 XFS 呢？ 這是有一些原因存在的：

EXT 家族當前較傷腦筋的地方：支援度最廣，但格式化超慢！

Ext 檔案系統家族對於檔案格式化的處理方面，採用的是預先規劃出所有的 inode/block/metadata 等資料，未來系統可以直接取用， 不需要再進行動態配置的作法。這個作法在早期磁碟容量還不大的時候還算 OK 沒啥問題，但時至今日，磁碟容量越來越大，連傳統的 MBR 都已經被 GPT 所取代，連我們這些老人家以前聽到的超大 TB 容量也已經不夠看了！現在都已經說到 PB 或 EB 以上容量了呢！那你可以想像得到，當你的 TB 以上等級的傳統 ext 家族檔案系統在格式化的時候，光是系統要預先分配 inode 與 block 就消耗你好多好多的人類時間了...

Tips 之前格式化過一個 70 TB 以上的磁碟陣列成為 ext4 檔案系統，按下格式化，去喝了咖啡、吃了便當才回來看做完了沒有... 所以，後來立刻改成 xfs 檔案系統了。

另外，由於虛擬化的應用越來越廣泛，而作為虛擬化磁碟來源的巨型檔案 （單一檔案好幾個GB 以上！） 也就越來越常見了。 這種巨型檔案在處理上需要考慮到效能問題，否則虛擬磁碟的效率就會不太好看。因此，從 CentOS 7.x 開始， 檔案系統已經由預設的 Ext4 變成了xfs 這一個較適合大容量磁碟與巨型檔案效能較佳的檔案系統了。

Tips 其實有幾組虛擬計算機教室伺服器系統，裡面跑的確實是 EXT4 檔案系統，老實說，並不覺得比 xfs 慢！所以，對鳥哥來說， 效能並不是主要改變檔案系統的考慮！對於檔案系統的復原速度、建立速度，可能才是鳥哥改換成 xfs 的思考點。

XFS 檔案系統的配置

基本上 xfs 就是一個日誌式檔案系統，而 CentOS 7.x 拿它當預設的檔案系統，自然就是因為最早之前，這個 xfs 就是被開發來用於大容量磁碟以及高效能檔案系統之用， 因此，相當適合現在的系統環境。此外，幾乎所有 Ext4 檔案系統有的功能， xfs 都可以具備！也因此在本小節前幾部份談到檔案系統時， 其實大部份的操作依舊是在 xfs 檔案系統環境下介紹給各位的哩！

xfs 檔案系統在資料的分佈上，主要規劃為三個部份，一個數據區 （data section）、一個檔案系統活動登入區 （log section）以及一個實時執行區 （realtime section）。 這三個區域的資料內容如下：

（1）資料區 （data section）

基本上，資料區就跟我們之前談到的 ext 家族一樣，包括 inode/data block/superblock 等資料，都放置在這個區塊。 這個資料區與 ext 家族的 block group 類似，也是分為多個儲存區群組 （allocation groups） 來分別放置檔案系統所需要的資料。 每個儲存區群組都包含了（1）整個檔案系統的 superblock、 （2）剩餘空間的管理機制、 （3）inode的分配與追蹤。此外，inode與 block 都是系統需要用到時， 這才動態配置產生，所以格式化動作超級快！

另外，與 ext 家族不同的是， xfs 的 block 與 inode 有多種不同的容量可供設定，block 容量可由 512Bytes ~ 64K 調配，不過，Linux 的環境下， 由於記憶體控制的關係 （分頁檔pagesize 的容量之故），因此最高可以使用的 block 大小為 4K 而已！（鳥哥嘗試格式化block 成為 16K 是沒問題的，不過，Linux 核心不給掛載！ 所以格式化完成後也無法使用啦！） 至於 inode 容量可由 256Bytes 到 2M 這麼大！不過，大概還是保留 256Bytes 的預設值就很夠用了！

Tips 總之， xfs 的這個資料區的儲存區群組 （allocation groups, AG），你就將它想成是 ext家族的 block 群組 （block groups） 就對了！本小節之前講的都可以在這個區塊內使用。 只是 inode 與 block 是動態產生，並非一開始於格式化就完成配置的。

（2）檔案系統活動登入區 （log section）

在登入區這個區域主要被用來紀錄檔案系統的變化，其實有點像是日誌區啦！檔案的變化會在這裡紀錄下來，直到該變化完整的寫入到資料區後， 該筆紀錄才會被終結。如果檔案系統因為某些緣故 （例如最常見的停電） 而損毀時，系統會拿這個登入區塊來進行檢驗，看看系統掛掉之前， 檔案系統正在執行些啥動作，藉以快速的修復檔案系統。

因為系統所有動作的時候都會在這個區塊做個紀錄，因此這個區塊的磁碟活動是相當頻繁的！xfs 設計有點有趣，在這個區域中， 你可以指定外部的磁碟來作為 xfs 檔案系統的日誌區塊喔！例如，你可以將 SSD 磁碟作為 xfs 的登入區，這樣當系統需要進行任何活動時， 就可以更快速的進行工作！相當有趣！

（3）實時執行區 （realtime section）

當有檔案要被建立時，xfs 會在這個區段裡面找一個到數個的 extent 區塊，將檔案放置在這個區塊內，等到分配完畢後，再寫入到 data section 的 inode 與 block 去！ 這個 extent 區塊的大小得要在格式化的時候就先指定，最小值是 4K 最大可到 1G。一般非磁碟陣列的磁碟預設為 64K 容量，而具有類似磁碟陣列的 stripe 情況下，則建議 extent 設定為與 stripe 一樣大較佳。這個 extent 最好不要亂動，因為可能會影響到實體磁碟的效能喔。

 

XFS 檔案系統的描述資料觀察

剛剛講了這麼多，完全無法理會耶～有沒有像 EXT 家族的 dumpe2fs 去觀察 superblock 內容的相關指令可以查閱呢？有啦！可以使用 xfs_info 去觀察的！ 詳細的指令作法可以參考如下：

[[email protected] ~]# xfs_info 掛載點|裝置檔名

範例一：找出系統 /boot 這個掛載點下面的檔案系統的 superblock 紀錄

[[email protected] ~]# df -T /boot

Filesystem Type 1K-blocks Used Available Use% Mounted on

/dev/vda2 xfs 1038336 133704 904632 13% /boot

# 沒錯！可以看得出來是 xfs 檔案系統的！來觀察一下內容吧！

[[email protected] ~]# xfs_info /dev/vda2

1 meta-data=/dev/vda2 isize=256 agcount=4, agsize=65536 blks

2 = sectsz=512 attr=2, projid32bit=1

3 = crc=0 finobt=0

4 data = bsize=4096 blocks=262144, imaxpct=25

5 = sunit=0 swidth=0 blks

6 naming =version 2 bsize=4096 ascii-ci=0 ftype=0

7 log =internal bsize=4096 blocks=2560, version=2

8 = sectsz=512 sunit=0 blks, lazy-count=1

9 realtime =none extsz=4096 blocks=0,

 

上面的輸出訊息可以這樣解釋：

第 1 行裡面的 isize 指的是 inode 的容量，每個有 256Bytes 這麼大。至於 agcount 則是前面談到的儲存區群組 （allocation group） 的個數，共有 4 個， agsize 則是指每個儲存區群組具有 65536 個 block 。配合第 4 行的 block 設定為 4K，因此整個檔案系統的容量應該就是 4655364K 這麼大！

第 2 行裡面 sectsz 指的是邏輯扇區 （sector） 的容量設定為 512Bytes 這麼大的意思。

第 4 行裡面的 bsize 指的是 block 的容量，每個 block 為 4K 的意思，共有 262144 個block 在這個檔案系統內。

第 5 行裡面的 sunit 與 swidth 與磁碟陣列的 stripe 相關性較高。這部份我們下面格式化的時候會舉一個例子來說明

第 7 行裡面的 internal 指的是這個登入區的位置在檔案系統內，而不是外部裝置的意思。且佔用了 4K * 2560 個 block，總共約 10M 的容量。

第 9 行裡面的 realtime 區域，裡面的 extent 容量為 4K。不過目前沒有使用。

 

由於我們並沒有使用磁碟陣列，因此上頭這個裝置裡頭的 sunit 與 extent 就沒有額外的指定特別的值。根據 xfs（5） 的說明，這兩個值會影響到你的檔案系統性能， 所以格式化的時候要特別留意喔！上面的說明大致上看看即可，比較重要的部份已經用特殊字型圈起來，你可以瞧一瞧先！