## 7.1 認識 Linux 文件系統 Linux 最傳統的磁盤文件系統 （filesystem） 使用的是 EXT2 這個啦！所以要了解 Linux 的文件系統就得要由認識 EXT2 開始！ 而文件系統是創建在磁盤上面的，因此我們得了解磁盤的物理組成才行。磁盤物理組成的部分我們在[第零章](../Text/index.html#pc_hd)談過了，至于磁盤分區則在[第二章](../Text/index.html#partition)談過了，所以下面只會很快的復習這兩部份。 重點在于 inode, block 還有 superblock 等文件系統的基本部分喔！ ### 7.1.1 磁盤組成與分區的復習 由于各項磁盤的物理組成我們在[第零章](../Text/index.html#pc_hd)里面就介紹過， 同時[第二章](../Text/index.html#partition)也談過分區的概念了，所以這個小節我們就拿之前的重點出來介紹就好了！ 詳細的信息請您回去那兩章自行復習喔！^_^。好了，首先說明一下磁盤的物理組成，整顆磁盤的組成主要有： * 圓形的盤片（主要記錄數據的部分）； * 機械手臂，與在機械手臂上的磁頭（可讀寫盤片上的數據）； * 主軸馬達，可以轉動盤片，讓機械手臂的磁頭在盤片上讀寫數據。 從上面我們知道數據儲存與讀取的重點在于盤片，而盤片上的物理組成則為（假設此磁盤為單碟片， 盤片圖示請參考[第二章圖2.2.1的示意](../Text/index.html#fig2.2.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 的分區？在[第三章的 CentOS 7 安裝](../Text/index.html)中， 鳥哥建議過強制使用 GPT 分區喔！所以本章后續的動作，大多還是以 GPT 為主來介紹喔！舊的 MBR 相關限制回去看看第二章吧！ ### 7.1.2 文件系統特性 我們都知道磁盤分區完畢后還需要進行格式化（format），之后操作系統才能夠使用這個文件系統。 為什么需要進行“格式化”呢？這是因為每種操作系統所設置的文件屬性/權限并不相同， 為了存放這些文件所需的數據，因此就需要將分區進行格式化，以成為操作系統能夠利用的“文件系統格式（filesystem）”。 由此我們也能夠知道，每種操作系統能夠使用的文件系統并不相同。 舉例來說，windows 98 以前的微軟操作系統主要利用的文件系統是 FAT （或 FAT16），windows 2000 以后的版本有所謂的 NTFS 文件系統，至于 Linux 的正統文件系統則為 Ext2 （Linux second extended file 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 內容讀出來！ 那么數據的讀取就如同下圖中的箭頭所指定的模樣了。 圖7.1.1、inode/block 數據存取示意圖 這種數據存取的方法我們稱為索引式文件系統（indexed allocation）。那有沒有其他的慣用文件系統可以比較一下啊？ 有的，那就是我們慣用的U盤（閃存），U盤使用的文件系統一般為 FAT 格式。FAT 這種格式的文件系統并沒有 inode 存在，所以 FAT 沒有辦法將這個文件的所有 block 在一開始就讀取出來。每個 block 號碼都記錄在前一個 block 當中， 他的讀取方式有點像下面這樣： 圖7.1.2、FAT文件系統數據存取示意圖 上圖中我們假設文件的數據依序寫入1->7->4->15號這四個 block 號碼中， 但這個文件系統沒有辦法一口氣就知道四個 block 的號碼，他得要一個一個的將 block 讀出后，才會知道下一個 block 在何處。 如果同一個文件數據寫入的 block 分散的太過厲害時，則我們的磁頭將無法在磁盤轉一圈就讀到所有的數據， 因此磁盤就會多轉好幾圈才能完整的讀取到這個文件的內容！ 常常會聽到所謂的“磁盤重組”吧？ 需要磁盤重組的原因就是文件寫入的 block 太過于離散了，此時文件讀取的性能將會變的很差所致。 這個時候可以通過磁盤重組將同一個文件所屬的 blocks 匯整在一起，這樣數據的讀取會比較容易啊！ 想當然爾，FAT 的文件系統需要三不五時的磁盤重組一下，那么 Ext2 是否需要磁盤重整呢？ 由于 Ext2 是索引式文件系統，基本上不太需要常常進行磁盤重組的。但是如果文件系統使用太久， 常常刪除/編輯/新增文件時，那么還是可能會造成文件數據太過于離散的問題，此時或許會需要進行重整一下的。 不過，老實說，鳥哥倒是沒有在 Linux 操作系統上面進行過 Ext2/Ext3 文件系統的磁盤重組說！似乎不太需要啦！^_^ ### 7.1.3 Linux 的 EXT2 文件系統（inode） 在[第五章](../Text/index.html)當中我們介紹過 Linux 的文件除了原有的數據內容外，還含有非常多的權限與屬性，這些權限與屬性是為了保護每個使用者所擁有數據的隱密性。 而前一小節我們知道 filesystem 里面可能含有的 inode/block/superblock 等。為什么要談這個呢？因為標準的 Linux 文件系統 Ext2 就是使用這種 inode 為基礎的文件系統啦！ 而如同前一小節所說的，inode 的內容在記錄文件的權限與相關屬性，至于 block 區塊則是在記錄文件的實際內容。 而且文件系統一開始就將 inode 與 block 規劃好了，除非重新格式化（或者利用 resize2fs 等指令變更文件系統大小），否則 inode 與 block 固定后就不再變動。但是如果仔細考慮一下，如果我的文件系統高達數百GB時， 那么將所有的 inode 與 block 通通放置在一起將是很不智的決定，因為 inode 與 block 的數量太龐大，不容易管理。 為此之故，因此 Ext2 文件系統在格式化的時候基本上是區分為多個區塊群組 （block group） 的，每個區塊群組都有獨立的 inode/block/superblock 系統。感覺上就好像我們在當兵時，一個營里面有分成數個連，每個連有自己的聯絡系統， 但最終都向營部回報連上最正確的信息一般！這樣分成一群群的比較好管理啦！整個來說，Ext2 格式化后有點像下面這樣： 圖7.1.3、ext2文件系統示意圖 [^[1]](#ps1) 在整體的規劃當中，文件系統最前面有一個開機扇區（boot sector），這個開機扇區可以安裝開機管理程序， 這是個非常重要的設計，因為如此一來我們就能夠將不同的開機管理程序安裝到個別的文件系統最前端，而不用覆蓋整顆磁盤唯一的 MBR， 這樣也才能夠制作出多重開機的環境啊！至于每一個區塊群組（block group）的六個主要內容說明如后： * data block （數據區塊） data block 是用來放置文件內容數據地方，在 Ext2 文件系統中所支持的 block 大小有 1K, 2K 及 4K 三種而已。在格式化時 block 的大小就固定了，且每個 block 都有編號，以方便 inode 的記錄啦。 不過要注意的是，由于 block 大小的差異，會導致該文件系統能夠支持的最大磁盤容量與最大單一文件大小并不相同。 因為 block 大小而產生的 Ext2 文件系統限制如下：[[2]](#ps2) | Block 大小 | 1KB | 2KB | 4KB | | --- | --- | --- | | 最大單一文件限制 | 16GB | 256GB | 2TB | | 最大文件系統總容量 | 2TB | 8TB | 16TB | 你需要注意的是，雖然 Ext2 已經能夠支持大于 2GB 以上的單一文件大小，不過某些應用程序依然使用舊的限制， 也就是說，某些程序只能夠捉到小于 2GB 以下的文件而已，這就跟文件系統無關了！ 舉例來說，鳥哥在環工方面的應用中有一套秀圖軟件稱為PAVE[[3]](#ps3)， 這套軟件就無法捉到鳥哥在數值模式仿真后產生的大于 2GB 以上的文件！所以后來只能找更新的軟件來取代它了！ 除此之外 Ext2 文件系統的 block 還有什么限制呢？有的！基本限制如下： * 原則上，block 的大小與數量在格式化完就不能夠再改變了（除非重新格式化）； * 每個 block 內最多只能夠放置一個文件的數據； * 承上，如果文件大于 block 的大小，則一個文件會占用多個 block 數量； * 承上，若文件小于 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 記錄的文件數據至少有下面這些：[[4]](#ps4) * 該文件的存取模式（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 的結構畫一下好了。 圖7.1.4、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 筆記錄，因此一個間接可以記錄的文件大小如上； * 雙間接： 256*256*1K=2562K 第一層 block 會指定 256 個第二層，每個第二層可以指定 256 個號碼，因此總額大小如上； * 三間接： 256*256*256*1K=2563K 第一層 block 會指定 256 個第二層，每個第二層可以指定 256 個第三層，每個第三層可以指定 256 個號碼，因此總額大小如上； * 總額：將直接、間接、雙間接、三間接加總，得到 12 + 256 + 256*256 + 256*256*256 （K） = 16GB 此時我們知道當文件系統將 block 格式化為 1K 大小時，能夠容納的最大文件為 16GB，比較一下[文件系統限制表](../Text/index.html#filesystem_limit)的結果可發現是一致的！但這個方法不能用在 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](../Text/index.html#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](../Text/index.html#dumpe2fs) 來觀察的。 * block bitmap （區塊對照表） 如果你想要新增文件時總會用到 block 吧！那你要使用哪個 block 來記錄呢？當然是選擇“空的 block ”來記錄新文件的數據啰。 那你怎么知道哪個 block 是空的？這就得要通過 block bitmap 的輔助了。從 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 的容量，使用默認方式來進行格式化的， 觀察的內容如下： ``` [root@study ~]# dumpe2fs [-bh] 設備文件名 選項與參數： -b ：列出保留為壞軌的部分（一般用不到吧！？） -h ：僅列出 superblock 的數據，不會列出其他的區段內容！ 范例：鳥哥的一塊 1GB ext4 文件系統內容 [root@study ~]# 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 了！ [root@study ~]# 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 號。 如果你對文件系統的詳細信息還有更多想要了解的話，那么請參考本章最后一小節的介紹喔！ 否則文件系統看到這里對于基礎認知您應該是已經相當足夠啦！下面則是要探討一下， 那么這個文件系統概念與實際的目錄樹應用有啥關連啊？ ### 7.1.4 與目錄樹的關系 由前一小節的介紹我們知道在 Linux 系統下，每個文件（不管是一般文件還是目錄文件）都會占用一個 inode ， 且可依據文件內容的大小來分配多個 block 給該文件使用。而由[第五章的權限說明](../Text/index.html#filepermission_dir)中我們知道目錄的內容在記錄文件名， 一般文件才是實際記錄數據內容的地方。那么目錄與文件在文件系統當中是如何記錄數據的呢？基本上可以這樣說： * 目錄 當我們在 Linux 下的文件系統創建一個目錄時，文件系統會分配一個 inode 與至少一塊 block 給該目錄。其中，inode 記錄該目錄的相關權限與屬性，并可記錄分配到的那塊 block 號碼； 而 block 則是記錄在這個目錄下的文件名與該文件名占用的 inode 號碼數據。也就是說目錄所占用的 block 內容在記錄如下的信息： 圖7.1.5、記載于目錄所屬的 block 內的文件名與 inode 號碼對應示意圖 如果想要實際觀察 root 主文件夾內的文件所占用的 inode 號碼時，可以使用 ls -i 這個選項來處理： ``` [root@study ~]# 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 嘛！ 看一下鳥哥的環境： ``` [root@study ~]# 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 我們在[第五章](../Text/index.html#dir)就講過該目錄不占磁盤容量， 所以當然耗用的 block 就是 0 啰！  **Tips** 由上面的結果我們知道目錄并不只會占用一個 block 而已，也就是說： 在目錄下面的文件數如果太多而導致一個 block 無法容納的下所有的文件名與 inode 對照表時，Linux 會給予該目錄多一個 block 來繼續記錄相關的數據； * 文件： 當我們在 Linux 下的 ext2 創建一個一般文件時， ext2 會分配一個 inode 與相對于該文件大小的 block 數量給該文件。例如：假設我的一個 block 為 4 KBytes ，而我要創建一個 100 KBytes 的文件，那么 linux 將分配一個 inode 與 25 個 block 來儲存該文件！ 但同時請注意，由于 inode 僅有 12 個直接指向，因此還要多一個 block 來作為區塊號碼的記錄喔！ * 目錄樹讀取： 好了，經過上面的說明你也應該要很清楚的知道 inode 本身并不記錄文件名，文件名的記錄是在目錄的 block 當中。 因此在[第五章文件與目錄的權限](../Text/index.html#filepermission_dir)說明中， 我們才會提到“新增/刪除/更名文件名與目錄的 w 權限有關”的特色！那么因為文件名是記錄在目錄的 block 當中， 因此當我們要讀取某個文件時，就務必會經過目錄的 inode 與 block ，然后才能夠找到那個待讀取文件的 inode 號碼， 最終才會讀到正確的文件的 block 內的數據。 由于目錄樹是由根目錄開始讀起，因此系統通過掛載的信息可以找到掛載點的 inode 號碼，此時就能夠得到根目錄的 inode 內容，并依據該 inode 讀取根目錄的 block 內的文件名數據，再一層一層的往下讀到正確的文件名。舉例來說，如果我想要讀取 /etc/passwd 這個文件時，系統是如何讀取的呢？ ``` [root@study ~]# 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 內容的數據讀出來。 * filesystem 大小與磁盤讀取性能： 另外，關于文件系統的使用效率上，當你的一個文件系統規劃的很大時，例如 100GB 這么大時， 由于磁盤上面的數據總是來來去去的，所以，整個文件系統上面的文件通常無法連續寫在一起（block 號碼不會連續的意思）， 而是填入式的將數據填入沒有被使用的 block 當中。如果文件寫入的 block 真的分的很散， 此時就會有所謂的文件數據離散的問題發生了。 如前所述，雖然我們的 ext2 在 inode 處已經將該文件所記錄的 block 號碼都記上了， 所以數據可以一次性讀取，但是如果文件真的太過離散，確實還是會發生讀取效率低落的問題。 因為磁頭還是得要在整個文件系統中來來去去的頻繁讀取！ 果真如此，那么可以將整個 filesystme 內的數據全部復制出來，將該 filesystem 重新格式化， 再將數據給他復制回去即可解決這個問題。 此外，如果 filesystem 真的太大了，那么當一個文件分別記錄在這個文件系統的最前面與最后面的 block 號碼中， 此時會造成磁盤的機械手臂移動幅度過大，也會造成數據讀取性能的低落。而且磁頭在搜尋整個 filesystem 時， 也會花費比較多的時間去搜尋！因此， partition 的規劃并不是越大越好， 而是真的要針對您的主機用途來進行規劃才行！^_^ ### 7.1.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 （是否有掛載） 與 filesystem state （clean 與否） 等狀態來判斷是否強制進行數據一致性的檢查！若有需要檢查時則以 [e2fsck](../Text/index.html#fsck) 這支程序來進行的。 不過，這樣的檢查真的是很費時～因為要針對 metadata 區域與實際數據存放區來進行比對， 呵呵～得要搜尋整個 filesystem 呢～如果你的文件系統有 100GB 以上，而且里面的文件數量又多時， 哇！系統真忙碌～而且在對 Internet 提供服務的服務器主機上面， 這樣的檢查真的會造成主機復原時間的拉長～真是麻煩～這也就造成后來所謂日志式文件系統的興起了。 * 日志式文件系統 （Journaling filesystem） 為了避免上述提到的文件系統不一致的情況發生，因此我們的前輩們想到一個方式， 如果在我們的 filesystem 當中規劃出一個區塊，該區塊專門在記錄寫入或修訂文件時的步驟， 那不就可以簡化一致性檢查的步驟了？也就是說： 1. 預備：當系統要寫入一個文件時，會先在日志記錄區塊中紀錄某個文件準備要寫入的信息； 2. 實際寫入：開始寫入文件的權限與數據；開始更新 metadata 的數據； 3. 結束：完成數據與 metadata 的更新后，在日志記錄區塊當中完成該文件的紀錄。 在這樣的程序當中，萬一數據的紀錄過程當中發生了問題，那么我們的系統只要去檢查日志記錄區塊， 就可以知道哪個文件發生了問題，針對該問題來做一致性的檢查即可，而不必針對整塊 filesystem 去檢查， 這樣就可以達到快速修復 filesystem 的能力了！這就是日志式文件最基礎的功能啰～ 那么我們的 ext2 可達到這樣的功能嗎？當然可以啊！ 就通過 ext3/ext4 即可！ ext3/ext4 是 ext2 的升級版本，并且可向下相容 ext2 版本呢！ 所以啰，目前我們才建議大家，可以直接使用 ext4 這個 filesystem 啊！ 如果你還記得 [dumpe2fs](../Text/index.html#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 的容量在處理日志呢！ 這樣對于所謂的日志式文件系統有沒有比較有概念一點呢？^_^。 ### 7.1.6 Linux 文件系統的運行 我們現在知道了目錄樹與文件系統的關系了，但是由[第零章](../Text/index.html)的內容我們也知道， 所有的數據都得要載入到內存后 CPU 才能夠對該數據進行處理。想一想，如果你常常編輯一個好大的文件， 在編輯的過程中又頻繁的要系統來寫入到磁盤中，由于磁盤寫入的速度要比內存慢很多， 因此你會常常耗在等待磁盤的寫入/讀取上。真沒效率！ 為了解決這個效率的問題，因此我們的 Linux 使用的方式是通過一個稱為非同步處理 （asynchronously） 的方式。所謂的非同步處理是這樣的： 當系統載入一個文件到內存后，如果該文件沒有被更動過，則在內存區段的文件數據會被設置為干凈（clean）的。 但如果內存中的文件數據被更改過了（例如你用 nano 去編輯過這個文件），此時該內存中的數據會被設置為臟的 （Dirty）。此時所有的動作都還在內存中執行，并沒有寫入到磁盤中！ 系統會不定時的將內存中設置為“Dirty”的數據寫回磁盤，以保持磁盤與內存數據的一致性。 你也可以利用[第四章談到的 sync](../Text/index.html#sync)指令來手動強迫寫入磁盤。 我們知道內存的速度要比磁盤快的多，因此如果能夠將常用的文件放置到內存當中，這不就會增加系統性能嗎？ 沒錯！是有這樣的想法！因此我們 Linux 系統上面文件系統與內存有非常大的關系喔： * 系統會將常用的文件數據放置到內存的緩沖區，以加速文件系統的讀/寫； * 承上，因此 Linux 的實體內存最后都會被用光！這是正常的情況！可加速系統性能； * 你可以手動使用 sync 來強迫內存中設置為 Dirty 的文件回寫到磁盤中； * 若正常關機時，關機指令會主動調用 sync 來將內存的數據回寫入磁盤內； * 但若不正常關機（如跳電、死機或其他不明原因），由于數據尚未回寫到磁盤內， 因此重新開機后可能會花很多時間在進行磁盤檢驗，甚至可能導致文件系統的損毀（非磁盤損毀）。 ### 7.1.7 掛載點的意義 （mount point） 每個 filesystem 都有獨立的 inode / block / superblock 等信息，這個文件系統要能夠鏈接到目錄樹才能被我們使用。 將文件系統與目錄樹結合的動作我們稱為“掛載”。 關于掛載的一些特性我們在[第二章](../Text/index.html#partition_install)稍微提過， 重點是：掛載點一定是目錄，該目錄為進入該文件系統的入口。 因此并不是你有任何文件系統都能使用，必須要“掛載”到目錄樹的某個目錄后，才能夠使用該文件系統的。 舉例來說，如果你是依據鳥哥的方法[安裝你的 CentOS 7.x](../Text/index.html) 的話， 那么應該會有三個掛載點才是，分別是 /, /boot, /home 三個 （鳥哥的系統上對應的設備文件名為 LVM, LVM, /dev/vda2）。 那如果觀察這三個目錄的 inode 號碼時，我們可以發現如下的情況： ``` [root@study ~]# 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 啰！ （因為每一行的文件屬性并不相同，且三個目錄的掛載點也均不相同之故。） 我們在[第六章一開始的路徑](../Text/index.html)中曾經提到根目錄下的 . 與 .. 是相同的東西， 因為權限是一模一樣嘛！如果使用文件系統的觀點來看，同一個 filesystem 的某個 inode 只會對應到一個文件內容而已（因為一個文件占用一個 inode 之故）， 因此我們可以通過判斷 inode 號碼來確認不同文件名是否為相同的文件喔！所以可以這樣看： ``` [root@study ~]# 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 號碼，當然這三個文件的內容也就完全一模一樣了！ 也就是說，根目錄的上層 （/..） 就是他自己！這么說，看的懂了嗎？ ^_^ ### 7.1.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 支持的文件系統有哪些，可以察看下面這個目錄： ``` [root@study ~]# ls -l /lib/modules/$（uname -r）/kernel/fs ``` 系統目前已載入到內存中支持的文件系統則有： ``` [root@study ~]# 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， 省去我們需要自行設置讀取文件系統的定義啊～方便很多！整個 VFS 可以約略用下圖來說明： 圖7.1.6、VFS 文件系統的示意圖 老實說，文件系統真的不好懂！ 如果你想要對文件系統有更深入的了解，文末的相關鏈接[[5]](#ps5)務必要參考參考才好喔！ ### 7.1.9 XFS 文件系統簡介 CentOS 7 開始，默認的文件系統已經由原本的 EXT4 變成了 XFS 文件系統了！為啥 CentOS 要舍棄對 Linux 支持度最完整的 EXT 家族而改用 XFS 呢？ 這是有一些原因存在的。 * EXT 家族當前較傷腦筋的地方：支持度最廣，但格式化超慢！ Ext 文件系統家族對于文件格式化的處理方面，采用的是預先規劃出所有的 inode/block/meta data 等數據，未來系統可以直接取用， 不需要再進行動態配置的作法。這個作法在早期磁盤容量還不大的時候還算 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 文件系統的配置 [[6]](#ps6) 基本上 xfs 就是一個日志式文件系統，而 CentOS 7.x 拿它當默認的文件系統，自然就是因為最早之前，這個 xfs 就是被開發來用于大容量磁盤以及高性能文件系統之用， 因此，相當適合現在的系統環境。此外，幾乎所有 Ext4 文件系統有的功能， xfs 都可以具備！也因此在本小節前幾部份談到文件系統時， 其實大部份的操作依舊是在 xfs 文件系統環境下介紹給各位的哩！ xfs 文件系統在數據的分佈上，主要規劃為三個部份，一個數據區 （data section）、一個文件系統活動登錄區 （log section）以及一個實時運行區 （realtime section）。 這三個區域的數據內容如下： * 數據區 （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 是動態產生，并非一開始于格式化就完成配置的。 * 文件系統活動登錄區 （log section） 在登錄區這個區域主要被用來紀錄文件系統的變化，其實有點像是日志區啦！文件的變化會在這里紀錄下來，直到該變化完整的寫入到數據區后， 該筆紀錄才會被終結。如果文件系統因為某些緣故 （例如最常見的停電） 而損毀時，系統會拿這個登錄區塊來進行檢驗，看看系統掛掉之前， 文件系統正在運行些啥動作，借以快速的修復文件系統。 因為系統所有動作的時候都會在這個區塊做個紀錄，因此這個區塊的磁盤活動是相當頻繁的！xfs 設計有點有趣，在這個區域中， 你可以指定外部的磁盤來作為 xfs 文件系統的日志區塊喔！例如，你可以將 SSD 磁盤作為 xfs 的登錄區，這樣當系統需要進行任何活動時， 就可以更快速的進行工作！相當有趣！ * 實時運行區 （realtime section） 當有文件要被創建時，xfs 會在這個區段里面找一個到數個的 extent 區塊，將文件放置在這個區塊內，等到分配完畢后，再寫入到 data section 的 inode 與 block 去！ 這個 extent 區塊的大小得要在格式化的時候就先指定，最小值是 4K 最大可到 1G。一般非磁盤陣列的磁盤默認為 64K 容量，而具有類似磁盤陣列的 stripe 情況下，則建議 extent 設置為與 stripe 一樣大較佳。這個 extent 最好不要亂動，因為可能會影響到實體磁盤的性能喔。 * XFS 文件系統的描述數據觀察 剛剛講了這么多，完全無法理會耶～有沒有像 EXT 家族的 dumpe2fs 去觀察 superblock 內容的相關指令可以查閱呢？有啦！可以使用 xfs_info 去觀察的！ 詳細的指令作法可以參考如下： ``` [root@study ~]# xfs_info 掛載點|設備文件名 范例一：找出系統 /boot 這個掛載點下面的文件系統的 superblock 紀錄 [root@study ~]# df -T /boot Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/vda2 xfs 1038336 133704 904632 13% /boot # 沒錯！可以看得出來是 xfs 文件系統的！來觀察一下內容吧！ [root@study ~]# 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, rtextents=0 ``` 上面的輸出訊息可以這樣解釋： * 第 1 行里面的 isize 指的是 inode 的容量，每個有 256Bytes 這么大。至于 agcount 則是前面談到的儲存區群組 （allocation group） 的個數，共有 4 個， agsize 則是指每個儲存區群組具有 65536 個 block 。配合第 4 行的 block 設置為 4K，因此整個文件系統的容量應該就是 4*65536*4K 這么大！ * 第 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） 的說明，這兩個值會影響到你的文件系統性能， 所以格式化的時候要特別留意喔！上面的說明大致上看看即可，比較重要的部份已經用特殊字體圈起來，你可以瞧一瞧先！