Linux 深刻理解inode/block/superblock

  

基礎命令學習目錄首頁

 

原文連接：https://blog.csdn.net/Ohmyberry/article/details/80427492

檔案系統特性

傳統的磁盤與檔案系統之應用中，一個分割槽就是隻可以被格式化成爲一個檔案系統，因此咱們能夠說一個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 內容讀出來！那麼資料的讀取就如同下圖中的箭頭所指定的模樣了。

這種資料存取的方法咱們稱爲索引式檔案系統(indexed allocation)。那有沒有其餘的慣用檔案系統能夠比較一下啊？有的，那就是咱們慣用的U盤(快閃記憶體)，U盤使用的檔案系統通常爲FAT格式。FAT這種格式的檔案系統並無inode存在，因此FAT沒有辦法將這個檔案的全部block在一開始就讀取出來。每一個block號碼都記錄在前一個block當中，他的讀取方式有點像底下這樣：

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

經常會聽到所謂的『碎片整理』吧？ 須要碎片整理的緣由就是檔案寫入的block太過於離散了，此時檔案讀取的效能將會變的不好所致。 這個時候能夠透過碎片整理將同一個檔案所屬的blocks彙整在一塊兒，這樣資料的讀取會比較容易啊！ 想固然爾，FAT的檔案系統須要三不五時的碎片整理一下，那麼Ext2是否須要磁盤重整呢？

因爲Ext2 是索引式檔案系統，基本上不太須要經常進行碎片整理的。可是若是檔案系統使用過久， 經常刪除/編輯/新增檔案時，那麼仍是可能會形成檔案資料太過於離散的問題，此時或許會須要進行重整一下的。

Linux 的EXT2 檔案系統(inode)

inode的內容在記錄檔案的權限與相關屬性，至於block區塊則是在記錄檔案的實際內容。並且檔案系統一開始就將inode與block規劃好了，除非從新格式化(或者利用resize2fs等指令變動檔案系統大小)，不然inode與block固定後就再也不變更。可是若是仔細考慮一下，若是個人檔案系統高達數百GB時，那麼將全部的inode與block統統放置在一塊兒將是很不智的決定，由於inode與block的數量太龐大，不容易管理。

爲此，所以Ext2 檔案系統在格式化的時候基本上是區分爲多個區塊羣組(block group) 的，每一個區塊羣組都有獨立的 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 檔案系統的block 還有什麼限制呢？有的！基本限制以下：

• 原則上，block 的大小與數量在格式化完就不可以再改變了(除非從新格式化)；
• 每一個block 內最多隻可以放置一個檔案的資料；
• 承上，若是檔案大於block 的大小，則一個檔案會佔用多個block 數量；
• 承上，若檔案小於block ，則該block 的剩餘容量就不可以再被使用了(磁盤空間會浪費)。

inode table (inode 表格)

基本上，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 可以指定多少個block 呢？咱們以較小的1K block 來講明好了，能夠指定的狀況以下：

• 12個直接指向： 12*1K=12K
  因爲是直接指向，因此總共可記錄12筆記錄，所以總額大小爲如上所示；
• 間接： 256*1K=256K
  每筆block號碼的記錄會花去4bytes，所以1K的大小可以記錄256筆記錄，所以一個間接能夠記錄的檔案大小如上；
• 雙間接： 256*256*1K=256 2 K
  第一層block會指定256個第二層，每一個第二層能夠指定256個號碼，所以總額大小如上；
• 三間接： 256*256*256*1K=256 3 K
  第一層block會指定256個第二層，每一個第二層能夠指定256個第三層，每一個第三層能夠指定256個號碼，所以總額大小如上；
• 總額：將直接、間接、雙間接、三間接加總，獲得12 + 256 + 256*256 + 256*256*256 (K) = 16GB

Superblock (超級區塊)

記錄的信息主要有：

• block 與inode 的總量；
• 未使用與已使用的inode / block 數量；
• block 與inode 的大小(block 爲1, 2, 4K，inode 爲128bytes 或256bytes)；
• filesystem 的掛載時間、最近一次寫入資料的時間、最近一次檢驗磁盤(fsck) 的時間等檔案系統的相關信息；
• 一個valid bit 數值，若此檔案系統已被掛載，則valid bit 爲0 ，若未被掛載，則valid bit 爲1 。

通常來講， 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 號碼囉！

dumpe2fs： 查詢Ext 家族superblock 信息的指令

[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 的號碼有關就是了！很重要！

 

至於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 號。

與目錄樹的關係

由前一小節的介紹咱們知道在Linux系統下，每一個檔案(無論是通常檔案仍是目錄檔案)都會佔用一個inode ，且可依據檔案內容的大小來分配多個block給該檔案使用。那麼目錄與檔案在檔案系統當中是如何記錄資料的呢？基本上能夠這樣說：

目錄

當咱們在Linux下的檔案系統創建一個目錄時，檔案系統會分配一個inode與至少一塊block給該目錄。其中，inode記錄該目錄的相關權限與屬性，並可記錄分配到的那塊block號碼；而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

 

而由這個目錄的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

檔案：

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

目錄樹讀取：

咱們提到『新增/刪除/改名檔名與目錄的w權限有關』！那是由於檔名是記錄在目錄的block當中，所以當咱們要讀取某個檔案時，就務必會通過目錄的inode與block ，而後纔可以找到那個待讀取檔案的inode號碼，最終纔會讀到正確的檔案的block內的資料。

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

[root@study ~]# ll -di / /etc /etc/passwd 128 dr-xr-x r-x . 17 root root 4096 May 4 17:56 / 33595521 drwxr-x r-x . 131 root root 8192 Jun 17 00:20 /etc 36628004 -rw-r-- r-- . 1 root root 2092 Jun 17 00:20 /etc/passw

 

該檔案的讀取流程爲(假設讀取者身份爲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內容的資料讀出來。