本文主要內容主要摘自鳥哥的Linux私房菜。參考內容來源： http://vbird.dic.ksu.edu.tw/linux_basic/0230filesystem.php#indexed_allocation
原文作者： vbird
文件系統特性我們都知道磁盤分區完畢後還需要進行格式化(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 的號碼有關就是了！很重要！ |
如上所示，利用 dumpe2fs 可以查詢到非常多的信息，不過依內容主要可以區分爲上半部是 superblock 內容， 下半部則是每個 block group 的信息了。從上面的表格中我們可以觀察到這個 /dev/hdc2 規劃的 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 則在 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 號。
如果你對文件系統的詳細信息還有更多想要了解的話，那麼請參考本章最後一小節的介紹喔！ 否則文件系統看到這裏對於基礎認知您應該是已經相當足夠啦！底下則是要探討一下， 那麼這個文件系統概念與實際的目錄樹應用有啥關連啊？
與目錄樹的關係由前一小節的介紹我們知道在 Linux 系統下，每個文件(不管是一般文件還是目錄文件)都會佔用一個 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 |
由於每個人所使用的計算機並不相同，系統安裝時選擇的項目與 partition 都不一樣，因此你的環境不可能與我的 inode 號碼一模一樣！上表的左邊所列出的 inode 僅是鳥哥的系統所顯示的結果而已！而由這個目錄的 block 結果我們現在就能夠知道， 當你使用『 ll / 』時，出現的目錄幾乎都是 1024 的倍數，爲什麼呢？因爲每個 block 的數量都是 1K, 2K, 4K 嘛！ 看一下鳥哥的環境：
[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 囉！
| 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 當中。 因此在第六章文件與目錄的權限說明中， 我們纔會提到『新增/刪除/更名文件名與目錄的 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 |
在鳥哥的系統上面與 /etc/passwd 有關的目錄與文件數據如上表所示，該文件的讀取流程爲(假設讀取者身份爲 vbird 這個一般身份使用者)：
- / 的 inode：
透過掛載點的信息找到 /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 |
看到了吧！透過 inode 8 號記錄 journal 區塊的 block 指向，而且具有 128MB 的容量在處理日誌呢！ 這樣對於所謂的日誌式文件系統有沒有比較有概念一點呢？^_^。如果想要知道爲什麼 Ext3 文件系統會更適用於目前的 Linux 系統， 我們可以參考 Red Hat 公司中，首席核心開發者 Michael K. Johnson 的話：(注6)
| 『爲什麼你想要從ext2轉換到ext3呢？有四個主要的理由：可利用性、數據完整性、速度及易於轉換』 『可利用性』，他指出，這意味着從系統中止到快速重新復原而不是持續的讓e2fsck運行長時間的修復。ext3
的日誌式條件可以避免數據毀損的可能。他也指出： 『除了寫入若干數據超過一次時，ext3往往會較快於ext2，因爲ext3的日誌使硬盤讀取頭的移動能更有效的進行』 然而或許決定的因素還是在Johnson先生的第四個理由中。 『它是可以輕易的從ext2變更到ext3來獲得一個強而有力的日誌式文件系統而不需要重新做格式化』。『那是正確的，爲了體驗一下 ext3 的好處是不需要去做一種長時間的，冗長乏味的且易於產生錯誤的備份工作及重新格式化的動作』。 |
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 號，因此可以發現 /, /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 /..
|
上面的信息中由於掛載點均爲 / ，因此三個文件 (/, /., /..) 均在同一個 filesystem 內，而這三個文件的 inode 號碼均爲 2 號，因此這三個檔名都指向同一個 inode 號碼，當然這三個文件的內容也就完全一模一樣了！ 也就是說，根目錄的上一級 (/..) 就是他自己！這麼說，看的懂了嗎？ ^_^