認識 EXT2 文件系統
Linux最傳統的磁盤文件系統(filesystem)使用的是EXT2這個啦！所以要了解文件系統就得要由認識EXT2開始！ 而文件系統是創建在硬盤上面的，因此我們得了解硬盤的物理組成才行，所以底下只會很快的復習這兩部份， 重點在於inode, block還有superblock等文件系統的基本部分喔！
硬盤組成與分割
首先說明一下磁盤的物理組成，整顆磁盤的組成主要有：
- 圓形的磁盤盤(主要記錄數據的部分)；
- 機械手臂，與在機械手臂上的磁盤讀取頭(可擦寫磁盤盤上的數據)；
- 主軸馬達，可以轉動磁盤盤，讓機械手臂的讀取頭在磁盤盤上讀寫數據。
從上面我們知道數據儲存與讀取的重點在於磁盤盤，而磁盤盤上的物理組成則為(假設此磁盤為單盤片， 磁盤盤圖標請參考下圖：
扇區(Sector)為最小的物理儲存單位，每個扇區為 512 bytes；
將扇區組成一個圓，那就是磁柱(Cylinder)，磁柱是分割槽(partition)的最小單位；
第一個扇區最重要，里面有：(1)主要啟動區(Master boot record, MBR)及分割表(partition table)， 其中 MBR 占有 446 bytes，而 partition table 則占有 64 bytes。
各種接口的磁盤在Linux中的文件名分別為：
/dev/sd[a-p][1-15]：為SCSI, SATA, U盤, Flash閃盤等接口的磁盤文件名；
/dev/hd[a-d][1-63]：為 IDE 接口的磁盤文件名；
復習完物理組成后，來復習一下磁盤分區吧！所謂的磁盤分區指的是告訴操作系統『我這顆磁盤在此分割槽可以存取的區域是由 A 磁柱到 B 磁柱之間的區塊』， 如此一來操作系統就能夠知道他可以在所指定的區塊內進行文件數據的讀/寫/搜尋等動作了。 也就是說，磁盤分區意即指定分割槽的啟始與結束磁柱就是了。
那么指定分割槽的磁柱范圍是記錄在哪里？就是第一個扇區的分割表中啦！但是因為分割表僅有64bytes而已， 因此最多只能記錄四筆分割槽的記錄，這四筆記錄我們稱為主要 (primary) 或延伸 (extended) 分割槽，其中擴展分配槽還可以再分割出邏輯分割槽 (logical) ， 而能被格式化的則僅有主要分割與邏輯分割而已。
最后，我們再將第三章關於分割的定義拿出來說明一下啰：
主要分割與擴展分隔最多可以有四筆(硬盤的限制)
擴展分配最多只能有一個(操作系統的限制)
邏輯分割是由擴展分配持續切割出來的分割槽；
能夠被格式化后，作為數據存取的分割槽為主要分割與邏輯分割。擴展分配無法格式化；
邏輯分割的數量依操作系統而不同，在Linux系統中，IDE硬盤最多有59個邏輯分割(5號到63號)， SATA硬盤則有11個邏輯分割(5號到15號)。
文件系統特性
我們都知道磁盤分區完畢后還需要進行格式化(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 內容讀出來！ 那么數據的讀取就如同下圖中的箭頭所指定的模樣了。
圖1.2.1、inode/block 數據存取示意圖
這種數據存取的方法我們稱為索引式文件系統(indexed allocation)。那有沒有其他的慣用文件系統可以比較一下啊？ 有的，那就是我們慣用的閃盤(閃存)，閃盤使用的文件系統一般為 FAT 格式。FAT 這種格式的文件系統並沒有 inode 存在，所以 FAT 沒有辦法將這個文件的所有 block 在一開始就讀取出來。每個 block 號碼都記錄在前一個 block 當中， 他的讀取方式有點像底下這樣：
圖1.2.2、FAT文件系統數據存取示意圖
上圖中我們假設文件的數據依序寫入1->7->4->15號這四個 block 號碼中， 但這個文件系統沒有辦法一口氣就知道四個 block 的號碼，他得要一個一個的將 block 讀出后，才會知道下一個 block 在何處。 如果同一個文件數據寫入的 block 分散的太過厲害時，則我們的磁盤讀取頭將無法在磁盤轉一圈就讀到所有的數據， 因此磁盤就會多轉好幾圈才能完整的讀取到這個文件的內容！
常常會聽到所謂的『碎片整理』吧？ 需要碎片整理的原因就是文件寫入的 block 太過於離散了，此時文件讀取的效能將會變的很差所致。 這個時候可以透過碎片整理將同一個文件所屬的 blocks 匯整在一起，這樣數據的讀取會比較容易啊！ 想當然爾，FAT 的文件系統需要經常的碎片整理一下，那么 Ext2 是否需要磁盤重整呢？
由於 Ext2 是索引式文件系統，基本上不太需要常常進行碎片整理的。但是如果文件系統使用太久， 常常刪除/編輯/新增文件時，那么還是可能會造成文件數據太過於離散的問題，此時或許會需要進行重整一下的。 不過，老實說，鳥哥倒是沒有在 Linux 操作系統上面進行過 Ext2/Ext3 文件系統的碎片整理說！似乎不太需要啦！^_^
Linux 的 EXT2 文件系統(inode)
我們介紹過 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 格式化后有點像底下這樣：
圖1.3.1、ext2文件系統示意圖( 注1)
在整體的規划當中，文件系統最前面有一個啟動扇區(boot sector)，這個啟動扇區可以安裝啟動管理程序， 這是個非常重要的設計，因為如此一來我們就能夠將不同的啟動管理程序安裝到個別的文件系統最前端，而不用覆蓋整顆硬盤唯一的 MBR， 這樣也才能夠制作出多重引導的環境啊！至於每一個區塊群組(block group)的六個主要內容說明如后：
data block (數據區塊)
data block 是用來放置文件內容數據地方，在 Ext2 文件系統中所支持的 block 大小有 1K, 2K 及 4K 三種而已。在格式化時 block 的大小就固定了，且每個 block 都有編號，以方便 inode 的記錄啦。 不過要注意的是，由於 block 大小的差異，會導致該文件系統能夠支持的最大磁盤容量與最大單一文件容量並不相同。 因為 block 大小而產生的 Ext2 文件系統限制如下：(注2)
| Block 大小 | 1KB | 2KB | 4KB |
| 最大單一文件限制 | 16GB | 256GB | 2TB |
| 最大文件系統總容量 | 2TB | 8TB | 16TB |
你需要注意的是，雖然 Ext2 已經能夠支持大於 2GB 以上的單一文件容量，不過某些應用程序依然使用舊的限制， 也就是說，某些程序只能夠捉到小於 2GB 以下的文件而已，這就跟文件系統無關了！ 舉例來說，鳥哥在環工方面的應用中有一套秀圖軟件稱為PAVE(注3)， 這套軟件就無法捉到鳥哥在數值模式仿真后產生的大於 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 號碼，讀寫起來也比較方便啊！
inode table (inode 表格)
再來討論一下 inode 這個玩意兒吧！如前所述 inode 的內容在記錄文件的屬性以及該文件實際數據是放置在哪幾號 block 內！ 基本上，inode 記錄的文件數據至少有底下這些：(注4)
- 該文件的存取模式(read/write/excute)；
- 該文件的擁有者與群組(owner/group)；
- 該文件的容量；
- 該文件創建或狀態改變的時間(ctime)；
- 最近一次的讀取時間(atime)；
- 最近修改的時間(mtime)；
- 定義文件特性的旗標(flag)，如 SetUID...；
- 該文件真正內容的指向 (pointer)；
inode 的數量與大小也是在格式化時就已經固定了，除此之外 inode 還有些什么特色呢？
- 每個 inode 大小均固定為 128 bytes；
- 每個文件都僅會占用一個 inode 而已；
- 承上，因此文件系統能夠創建的文件數量與 inode 的數量有關；
- 系統讀取文件時需要先找到 inode，並分析 inode 所記錄的權限與用戶是否符合，若符合才能夠開始實際讀取 block 的內容。
我們約略來分析一下 inode / block 與文件大小的關系好了。inode 要記錄的數據非常多，但偏偏又只有 128bytes 而已， 而 inode 記錄一個 block 號碼要花掉 4byte ，假設我一個文件有 400MB 且每個 block 為 4K 時， 那么至少也要十萬筆 block 號碼的記錄呢！inode 哪有這么多可記錄的信息？為此我們的系統很聰明的將 inode 記錄 block 號碼的區域定義為12個直接，一個間接, 一個雙間接與一個三間接記錄區。這是啥？我們將 inode 的結構畫一下好了。
圖1.3.2、inode 結構示意圖( 注5)
上圖最左邊為 inode 本身 (128 bytes)，里面有 12 個直接指向 block 號碼的對照，這 12 筆記錄就能夠直接取得 block 號碼啦！ 至於所謂的間接就是再拿一個 block 來當作記錄 block 號碼的記錄區，如果文件太大時， 就會使用間接的 block 來記錄編號。如上圖 1.3.2 當中間接只是拿一個 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，比較一下文件系統限制表的結果可發現是一致的！但這個方法不能用在 2K 及 4K block 大小的計算中， 因為大於 2K 的 block 將會受到 Ext2 文件系統本身的限制，所以計算的結果會不太符合之故。
Superblock (超級區塊)
Superblock 是記錄整個 filesystem 相關信息的地方， 沒有 Superblock ，就沒有這個 filesystem 了。他記錄的信息主要有：
- block 與 inode 的總量；
- 未使用與已使用的 inode / block 數量；
- block 與 inode 的大小 (block 為 1, 2, 4K，inode 為 128 bytes)；
- 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 是空的？這就得要透過 block bitmap 的輔助了。從 block bitmap 當中可以知道哪些 block 是空的，因此我們的系統就能夠很快速的找到可使用的空間來處置文件啰。
同樣的，如果你刪除某些文件時，那么那些文件原本占用的 block 號碼就得要釋放出來， 此時在 block bitmap 當中相對應到該 block 號碼的標志就得要修改成為『未使用中』啰！這就是 bitmap 的功能。
inode bitmap (inode 對照表)
這個其實與 block bitmap 是類似的功能，只是 block bitmap 記錄的是使用與未使用的 block 號碼， 至於 inode bitmap 則是記錄使用與未使用的 inode 號碼啰！
了解了文件系統的概念之后，再來當然是觀察這個文件系統啰！剛剛談到的各部分數據都與 block 號碼有關！ 每個區段與 superblock 的信息都可以使用 dumpe2fs 這個命令來查詢的！查詢的方法與實際的觀察如下：
[root@www ~]# dumpe2fs [-bh] 裝置文件名 選項與參數： -b ：列出保留為壞軌的部分(一般用不到吧！？) -h ：僅列出 superblock 的數據，不會列出其他的區段內容！ 范例：找出我的根目錄磁盤文件名，並觀察文件系統的相關信息 [root@www ~]# df <==這個命令可以叫出目前掛載的裝置 Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdc2 9920624 3822848 5585708 41% / <==就是這個光！ /dev/hdc3 4956316 141376 4559108 4% /home /dev/hdc1 101086 11126 84741 12% /boot tmpfs 371332 0 371332 0% /dev/shm [root@www ~]# dumpe2fs /dev/hdc2 dumpe2fs 1.39 (29-May-2006) Filesystem volume name: /1 <==這個是文件系統的名稱(Label) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Default mount options: user_xattr acl <==默認掛載的參數 Filesystem state: clean <==這個文件系統是沒問題的(clean) Errors behavior: Continue Filesystem OS type: Linux Inode count: 2560864 <==inode的總數 Block count: 2560359 <==block的總數 Free blocks: 1524760 <==還有多少個 block 可用 Free inodes: 2411225 <==還有多少個 inode 可用 First block: 0 Block size: 4096 <==每個 block 的大小啦！ Filesystem created: Fri Sep 5 01:49:20 2008 Last mount time: Mon Sep 22 12:09:30 2008 Last write time: Mon Sep 22 12:09:30 2008 Last checked: Fri Sep 5 01:49:20 2008 First inode: 11 Inode size: 128 <==每個 inode 的大小 Journal inode: 8 <==底下這三個與下一小節有關 Journal backup: inode blocks Journal size: 128M Group 0: (Blocks 0-32767) <==第一個 data group 內容, 包含 block 的啟始/結束號碼 Primary superblock at 0, Group descriptors at 1-1 <==超級區塊在 0 號 block Reserved GDT blocks at 2-626 Block bitmap at 627 (+627), Inode bitmap at 628 (+628) Inode table at 629-1641 (+629) <==inode table 所在的 block 0 free blocks, 32405 free inodes, 2 directories <==所有 block 都用完了！ Free blocks: Free inodes: 12-32416 <==剩余未使用的 inode 號碼 Group 1: (Blocks 32768-65535) ....(底下省略).... # 由於數據量非常的龐大，因此鳥哥將一些信息省略輸出了！上表與你的屏幕會有點差異。 # 前半部在秀出 supberblock 的內容，包括標頭名稱(Label)以及inode/block的相關信息 # 后面則是每個 block group 的個別信息了！您可以看到各區段數據所在的號碼！ # 也就是說，基本上所有的數據還是與 block 的號碼有關就是了！很重要！
至於 block group 的內容我們單純看 Group0 信息好了。從上表中我們可以發現：如上所示，利用 dumpe2fs 可以查詢到非常多的信息，不過依內容主要可以區分為上半部是 superblock 內容， 下半部則是每個 block group 的信息了。從上面的表格中我們可以觀察到這個 /dev/hdc2 規划的 block 為 4K， 第一個 block 號碼為 0 號，且 block group 內的所有信息都以 block 的號碼來表示的。 然后在 superblock 中還有談到目前這個文件系統的可用 block 與 inode 數量喔！
- Group0 所占用的 block 號碼由 0 到 32767 號，superblock 則在第 0 號的 block 區塊內！
- 文件系統描述說明在第 1 號 block 中；
- block bitmap 與 inode bitmap 則在 627 及 628 的 block 號碼上。
- 至於 inode table 分布於 629-1641 的 block 號碼中！
- 由於 (1)一個 inode 占用 128 bytes ，(2)總共有 1641 - 629 + 1(629本身) = 1013 個 block 花在 inode table 上， (3)每個 block 的大小為 4096 bytes(4K)。由這些數據可以算出 inode 的數量共有 1013 * 4096 / 128 = 32416 個 inode 啦！
- 這個 Group0 目前沒有可用的 block 了，但是有剩余 32405 個 inode 未被使用；
- 剩余的 inode 號碼為 12 號到 32416 號。
如果你對文件系統的詳細信息還有更多想要了解的話，那么請參考本章最后一小節的介紹喔！ 否則文件系統看到這里對於基礎認知您應該是已經相當足夠啦！底下則是要探討一下， 那么這個文件系統概念與實際的目錄樹應用有啥關連啊？
ext2和目錄樹
每個文件(不管是一般文件還是目錄文件)都會占用一個 inode ， 且可依據文件內容的大小來分配多個 block 給該文件使用。而我們知道目錄的內容在記錄文件名， 一般文件才是實際記錄數據內容的地方。那么目錄與文件在 Ext2 文件系統當中是如何記錄數據的呢？
目錄
當我們在 Linux 下的 ext2 文件系統創建一個目錄時， ext2 會分配一個 inode 與至少一塊 block 給該目錄。其中，inode 記錄該目錄的相關權限與屬性，並可記錄分配到的那塊 block 號碼； 而 block 則是記錄在這個目錄下的文件名與該文件名占用的 inode 號碼數據。也就是說目錄所占用的 block 內容在記錄如下的信息：
圖1.4.1、目錄占用的 block 記錄的數據示意圖
如果想要實際觀察 root 家目錄內的文件所占用的 inode 號碼時，可以使用 ls -i 這個選項來處理：
[root@www ~]# ls -li total 92 654683 -rw------- 1 root root 1474 Sep 4 18:27 anaconda-ks.cfg 648322 -rw-r--r-- 1 root root 42304 Sep 4 18:26 install.log 648323 -rw-r--r-- 1 root root 5661 Sep 4 18:25 install.log.syslog
[root@www ~]# ll -d / /bin /boot /proc /lost+found /sbin drwxr-xr-x 23 root root 4096 Sep 22 12:09 / <==一個 4K block drwxr-xr-x 2 root root 4096 Sep 24 00:07 /bin <==一個 4K block drwxr-xr-x 4 root root 1024 Sep 4 18:06 /boot <==一個 1K block drwx------ 2 root root 16384 Sep 5 01:49 /lost+found <==四個 4K block dr-xr-xr-x 96 root root 0 Sep 22 20:07 /proc <==此目錄不占硬盤空間 drwxr-xr-x 2 root root 12288 Sep 5 12:33 /sbin <==三個 4K block
由於鳥哥的根目錄 /dev/hdc2 使用的 block 大小為 4K ，因此每個目錄幾乎都是 4K 的倍數。 其中由於 /sbin 的內容比較復雜因此占用了 3 個 block ，此外，鳥哥的系統中 /boot 為獨立的 partition ， 該 partition 的 block 為 1K 而已，因此該目錄就僅占用 1024 bytes 的大小啰！至於奇怪的 /proc 我們講過該目錄不占硬盤容量， 所以當然耗用的 block 就是 0 啰！由於每個人所使用的計算機並不相同，系統安裝時選擇的項目與 partition 都不一樣，因此你的環境不可能與我的 inode 號碼一模一樣！上表的左邊所列出的 inode 僅是鳥哥的系統所顯示的結果而已！而由這個目錄的 block 結果我們現在就能夠知道， 當你使用『 ll / 』時，出現的目錄幾乎都是 1024 的倍數，為什么呢？因為每個 block 的數量都是 1K, 2K, 4K 嘛！ 看一下鳥哥的環境：
備注：由上面的結果我們知道目錄並不只會占用一個 block 而已，也就是說： 在目錄底下的文件數如果太多而導致一個 block 無法容納的下所有的檔名與 inode 對照表時，Linux 會給予該目錄多一個 block 來繼續記錄相關的數據。
文件
當我們在 Linux 下的 ext2 創建一個一般文件時， ext2 會分配一個 inode 與相對於該文件大小的 block 數量給該文件。例如：假設我的一個 block 為 4 Kbytes ，而我要創建一個 100 KBytes 的文件，那么 linux 將分配一個 inode 與 25 個 block 來儲存該文件！ 但同時請注意，由於 inode 僅有 12 個直接指向，因此還要多一個 block 來作為區塊號碼的記錄喔！
目錄樹讀取
好了，經過上面的說明你也應該要很清楚的知道 inode 本身並不記錄文件名，文件名的記錄是在目錄的 block 當中。 因此 我們才會提到『新增/刪除/更名文件名與目錄的 w 權限有關』的特色！那么因為文件名是記錄在目錄的 block 當中， 因此當我們要讀取某個文件時，就務必會經過目錄的 inode 與 block ，然后才能夠找到那個待讀取文件的 inode 號碼， 最終才會讀到正確的文件的 block 內的數據。
由於目錄樹是由根目錄開始讀起，因此系統透過掛載的信息可以找到掛載點的 inode 號碼(通常一個 filesystem 的最頂層 inode 號碼會由 2 號開始喔！)，此時就能夠得到根目錄的 inode 內容，並依據該 inode 讀取根目錄的 block 內的文件名數據，再一層一層的往下讀到正確的檔名。
舉例來說，如果我想要讀取 /etc/passwd 這個文件時，系統是如何讀取的呢？
[root@www ~]# ll -di / /etc /etc/passwd 2 drwxr-xr-x 23 root root 4096 Sep 22 12:09 / 1912545 drwxr-xr-x 105 root root 12288 Oct 14 04:02 /etc 1914888 -rw-r--r-- 1 root root 1945 Sep 29 02:21 /etc/passwd
/ 的 inode：在鳥哥的系統上面與 /etc/passwd 有關的目錄與文件數據如上表所示，該文件的讀取流程為(假設讀取者身份為 vbird 這個一般身份使用者)：
- 透過掛載點的信息找到 /dev/hdc2 的 inode 號碼為 2 的根目錄 inode，且 inode 規范的權限讓我們可以讀取該 block 的內容(有 r 與 x) ；
- / 的 block：
經過上個步驟取得 block 的號碼，並找到該內容有 etc/ 目錄的 inode 號碼 (1912545)； - etc/ 的 inode：
讀取 1912545 號 inode 得知 vbird 具有 r 與 x 的權限，因此可以讀取 etc/ 的 block 內容； - etc/ 的 block：
經過上個步驟取得 block 號碼，並找到該內容有 passwd 文件的 inode 號碼 (1914888)； - passwd 的 inode：
讀取 1914888 號 inode 得知 vbird 具有 r 的權限，因此可以讀取 passwd 的 block 內容； - passwd 的 block：
最后將該 block 內容的數據讀出來。
filesystem 大小與磁盤讀取效能
另外，關於文件系統的使用效率上，當你的一個文件系統規划的很大時，例如 100GB 這么大時， 由於硬盤上面的數據總是來來去去的，所以，整個文件系統上面的文件通常無法連續寫在一起(block 號碼不會連續的意思)， 而是填入式的將數據填入沒有被使用的 block 當中。如果文件寫入的 block 真的分的很散， 此時就會有所謂的文件數據離散的問題發生了。
如前所述，雖然我們的 ext2 在 inode 處已經將該文件所記錄的 block 號碼都記上了， 所以數據可以一次性讀取，但是如果文件真的太過離散，確實還是會發生讀取效率低落的問題。 因為磁盤讀取頭還是得要在整個文件系統中來來去去的頻繁讀取！ 果真如此，那么可以將整個 filesystme 內的數據全部復制出來，將該 filesystem 重新格式化， 再將數據給他復制回去即可解決這個問題。
此外，如果 filesystem 真的太大了，那么當一個文件分別記錄在這個文件系統的最前面與最后面的 block 號碼中， 此時會造成硬盤的機械手臂移動幅度過大，也會造成數據讀取效能的低落。而且讀取頭在搜尋整個 filesystem 時， 也會花費比較多的時間去搜尋！因此， partition 的規划並不是越大越好， 而是真的要針對您的主機用途來進行規划才行！^_^
EXT2/EXT3 文件的存取與日志式文件系統的功能
上一小節談到的僅是讀取而已，那么如果是新建一個文件或目錄時，我們的 Ext2 是如何處理的呢？ 這個時候就得要 block bitmap 及 inode bitmap 的幫忙了！假設我們想要新增一個文件，此時文件系統的行為是：
- 先確定用戶對於欲新增文件的目錄是否具有 w 與 x 的權限，若有的話才能新增；
- 根據 inode bitmap 找到沒有使用的 inode 號碼，並將新文件的權限/屬性寫入；
- 根據 block bitmap 找到沒有使用中的 block 號碼，並將實際的數據寫入 block 中，且升級 inode 的 block 指向數據；
- 將剛剛寫入的 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 這支程序來進行的。
不過，這樣的檢查真的是很費時～因為要針對 metadata 區域與實際數據存放區來進行比對， 呵呵～得要搜尋整個 filesystem 呢～如果你的文件系統有 100GB 以上，而且里面的文件數量又多時， 哇！系統真忙碌～而且在對 Internet 提供服務的服務器主機上面， 這樣的檢查真的會造成主機復原時間的拉長～真是麻煩～這也就造成后來所謂日志式文件系統的興起了。
日志式文件系統 (Journaling filesystem)
為了避免上述提到的文件系統不一致的情況發生，因此我們的前輩們想到一個方式， 如果在我們的 filesystem 當中規划出一個區塊，該區塊專門在記錄寫入或修訂文件時的步驟， 那不就可以簡化一致性檢查的步驟了？也就是說：
- 預備：當系統要寫入一個文件時，會先在日志記錄區塊中紀錄某個文件准備要寫入的信息；
- 實際寫入：開始寫入文件的權限與數據；開始升級 metadata 的數據；
- 結束：完成數據與 metadata 的升級后，在日志記錄區塊當中完成該文件的紀錄。
在這樣的程序當中，萬一數據的紀錄過程當中發生了問題，那么我們的系統只要去檢查日志記錄區塊， 就可以知道哪個文件發生了問題，針對該問題來做一致性的檢查即可，而不必針對整塊 filesystem 去檢查， 這樣就可以達到快速修復 filesystem 的能力了！這就是日志式文件最基礎的功能啰～
那么我們的 ext2 可達到這樣的功能嗎？當然可以啊！ 就透過 ext3 即可！ ext3 是 ext2 的升級版本，並且可向下兼容 ext2 版本呢！ 所以啰，目前我們才建議大家，可以直接使用 ext3 這個 filesystem 啊！ 如果你還記得 dumpe2fs 輸出的信息，可以發現 superblock 里面含有底下這樣的信息：
Journal inode: 8 Journal backup: inode blocks Journal size: 128M
『為什么你想要從ext2轉換到ext3呢？有四個主要的理由：可利用性、數據完整性、速度及易於轉換』 『可利用性』，他指出，這意味着從系統中止到快速重新復原而不是持續的讓e2fsck運行長時間的修復。ext3 的日志式條件可以避免數據毀損的可能。他也指出： 『除了寫入若干數據超過一次時，ext3往往會較快於ext2，因為ext3的日志使硬盤讀取頭的移動能更有效的進行』 然而或許決定的因素還是在Johnson先生的第四個理由中。
『它是可以輕易的從ext2變更到ext3來獲得一個強而有力的日志式文件系統而不需要重新做格式化』。『那是正確的，為了體驗一下 ext3 的好處是不需要去做一種長時間的，冗長乏味的且易於產生錯誤的備份工作及重新格式化的動作』。
看到了吧！透過 inode 8 號記錄 journal 區塊的 block 指向，而且具有 128MB 的容量在處理日志呢！ 這樣對於所謂的日志式文件系統有沒有比較有概念一點呢？^_^。如果想要知道為什么 Ext3 文件系統會更適用於目前的 Linux 系統， 我們可以參考 Red Hat 公司中，首席核心開發者 Michael K. Johnson 的話
Linux 文件系統的運行
我們現在知道了目錄樹與文件系統的關系了，我們也知道， 所有的數據都得要加載到內存后 CPU 才能夠對該數據進行處理。想一想，如果你常常編輯一個好大的文件， 在編輯的過程中又頻繁的要系統來寫入到磁盤中，由於磁盤寫入的速度要比內存慢很多， 因此你會常常耗在等待硬盤的寫入/讀取上。真沒效率！
為了解決這個效率的問題，因此我們的 Linux 使用的方式是透過一個稱為異步處理 (asynchronously) 的方式。所謂的異步處理是這樣的：
當系統加載一個文件到內存后，如果該文件沒有被更動過，則在內存區段的文件數據會被配置為干凈(clean)的。 但如果內存中的文件數據被更改過了(例如你用 nano 去編輯過這個文件)，此時該內存中的數據會被配置為臟的 (Dirty)。此時所有的動作都還在內存中運行，並沒有寫入到磁盤中！ 系統會不定時的將內存中配置為『Dirty』的數據寫回磁盤，以保持磁盤與內存數據的一致性。 你也可以利用 sync命令來手動強迫寫入磁盤。
我們知道內存的速度要比硬盤快的多，因此如果能夠將常用的文件放置到內存當中，這不就會添加系統性能嗎？ 沒錯！是有這樣的想法！因此我們 Linux 系統上面文件系統與內存有非常大的關系喔：
- 系統會將常用的文件數據放置到主存儲器的緩沖區，以加速文件系統的讀/寫；
- 承上，因此 Linux 的物理內存最后都會被用光！這是正常的情況！可加速系統效能；
- 你可以手動使用 sync 來強迫內存中配置為 Dirty 的文件回寫到磁盤中；
- 若正常關機時，關機命令會主動呼叫 sync 來將內存的數據回寫入磁盤內；
- 但若不正常關機(如跳電、死機或其他不明原因)，由於數據尚未回寫到磁盤內， 因此重新啟動后可能會花很多時間在進行磁盤檢驗，甚至可能導致文件系統的損毀(非磁盤損毀)。
掛載點的意義 (mount point)
每個 filesystem 都有獨立的 inode / block / superblock 等信息，這個文件系統要能夠鏈接到目錄樹才能被我們使用。 將文件系統與目錄樹結合的動作我們稱為『掛載』。 關於掛載的一些特性我們在稍微提過， 重點是：掛載點一定是目錄，該目錄為進入該文件系統的入口。 因此並不是你有任何文件系統都能使用，必須要『掛載』到目錄樹的某個目錄后，才能夠使用該文件系統的。
舉例來說，如果你是依據鳥哥的方法安裝你的 CentOS 5.x 的話， 那么應該會有三個掛載點才是，分別是 /, /boot, /home 三個 (鳥哥的系統上對應的裝置文件名為 /dev/hdc2, /dev/hdc1, /dev/hdc3)。 那如果觀察這三個目錄的 inode 號碼時，我們可以發現如下的情況：
[root@www ~]# ls -lid / /boot /home 2 drwxr-xr-x 23 root root 4096 Sep 22 12:09 / 2 drwxr-xr-x 4 root root 1024 Sep 4 18:06 /boot 2 drwxr-xr-x 6 root root 4096 Sep 29 02:21 /home
上面的信息中由於掛載點均為 / ，因此三個文件 (/, /., /..) 均在同一個 filesystem 內，而這三個文件的 inode 號碼均為 2 號，因此這三個檔名都指向同一個 inode 號碼，當然這三個文件的內容也就完全一模一樣了！ 也就是說，根目錄的上一級 (/..) 就是他自己！這么說，看的懂了嗎？ ^_^看到了吧！
由於 filesystem 最頂層的目錄之 inode 一般為 2 號，因此可以發現 /, /boot, /home 為三個不同的 filesystem 啰！ (因為每一行的文件屬性並不相同，且三個目錄的掛載點也均不相同之故。)
我們曾經提到根目錄下的 . 與 .. 是相同的東西， 因為權限是一模一樣嘛！如果使用文件系統的觀點來看，同一個 filesystem 的某個 inode 只會對應到一個文件內容而已(因為一個文件占用一個 inode 之故)， 因此我們可以透過判斷 inode 號碼來確認不同文件名是否為相同的文件喔！所以可以這樣看：
[root@www ~]# ls -ild / /. /.. 2 drwxr-xr-x 23 root root 4096 Sep 22 12:09 / 2 drwxr-xr-x 23 root root 4096 Sep 22 12:09 /. 2 drwxr-xr-x 23 root root 4096 Sep 22 12:09 /..
其他 Linux 支持的文件系統與 VFS
雖然 Linux 的標准文件系統是 ext2 ，且還有添加了日志功能的 ext3 ，事實上，Linux 還有支持很多文件系統格式的， 尤其是最近這幾年推出了好幾種速度很快的日志式文件系統，包括 SGI 的 XFS 文件系統， 可以適用更小型文件的 Reiserfs 文件系統，以及 Windows 的 FAT 文件系統等等， 都能夠被 Linux 所支持喔！常見的支持文件系統有：
- 傳統文件系統：ext2 / minix / MS-DOS / FAT (用 vfat 模塊) / iso9660 (光盤)等等；
- 日志式文件系統： ext3 / ReiserFS / Windows' NTFS / IBM's JFS / SGI's XFS
- 網絡文件系統： NFS / SMBFS
想要知道你的 Linux 支持的文件系統有哪些，可以察看底下這個目錄：
[root@www ~]# ls -l /lib/modules/$(uname -r)/kernel/fs
Linux VFS (Virtual Filesystem Switch)系統目前已加載到內存中支持的文件系統則有：
[root@www ~]# cat /proc/filesystems
了解了我們使用的文件系統之后，再來則是要提到，那么 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 可以約略用下圖來說明：
圖 1.8.1、VFS 文件系統的示意圖