linux點陣圖
㈠ 程序員必備知識（操作系統5-文件系統）
本篇與之前的第三篇的內存管理知識點有相似的地方
對於運行的進程來說，內存就像一個紙箱子, 僅僅是一個暫存數據的地方， 而且空間有限。如果我們想要進程結束之後，數據依然能夠保存下來，就不能只保存在內存里，而是應該保存在 外部存儲 中。就像圖書館這種地方，不僅空間大,而且能夠永久保存。
我們最常用的外部存儲就是 硬碟 ，數據是以文件的形式保存在硬碟上的。為了管理這些文件，我們在規劃文件系統的時候，需要考慮到以下幾點。
第一點,文件系統要有嚴格的組織形式，使得文件能夠 以塊為單位進行存儲 。這就像圖書館里，我們會給設置一排排書架，然後再把書架分成一個個小格子，有的項目存放的資料非常多，一個格子放不下，就需要多個格子來進行存放。我們把這個區域稱為存放原始資料的 倉庫區 。
第二點,文件系統中也要有 索引區 ，用來方便查找一個文件分成的多個塊都存放在了什麼位置。這就好比，圖書館的書太多了,為了方便查找,我們需要專門設置一排書架,這裡面會寫清楚整個檔案庫有哪些資料,資料在哪個架子的哪個格子上。這樣找資料的時候就不用跑遍整個檔案庫,在這個書架上找到後，直奔目標書架就可以了。
第三點,如果文件系統中有的文件是熱點文件,近期經常被讀取和寫入，文件系統應該有 緩存層 。這就相當於圖書館裡面的熱門圖書區,這裡面的書都是暢銷書或者是常常被借還的圖書。因為借還的次數比較多,那就沒必要每次有人還了之後，還放回遙遠的貨架，我們可以專門開辟一個區域, 放置這些借還頻次高的圖書。這樣借還的效率就會提高。
第四點,文件應該用 文件夾 的形式組織起來，方便管理和查詢。這就像在圖書館裡面，你可以給這些資料分門別類,比如分成計算機類.文學類.歷史類等等。這樣你也容易管理，項目組借閱的時候只要在某個類別中去找就可以了。
在文件系統中，每個文件都有一個名字,這樣我們訪問一個文件，希望通過它的名字就可以找到。文件名就是一個普通的文本。 當然文件名會經常沖突,不同用戶取相同的名字的情況還是會經常出現的。
要想把很多的文件有序地組織起來,我們就需要把它們成為 目錄 或者文件夾。這樣,一個文件夾里可以包含文件夾,也可以包含文件,這樣就形成了一種 樹形結構 。而我們可以將不同的用戶放在不同的用戶目錄下，就可以一定程度上避免了命名的沖突問題。
第五點，linux 內核要在自己的內存裡面維護一套數據結構，來保存哪些文件被哪些進程打開和使用 。這就好比，圖書館里會有個圖書管理系統，記錄哪些書被借閱了，被誰借閱了，借閱了多久,什麼時候歸還。
文件系統是操作系統中負責管理持久數據的子系統，說簡單點,就是負責把用戶的文件存到磁碟硬體中,因為即使計算機斷電了，磁碟里的數據並不會丟失,所以可以持久化的保存文件。
文件系統的基本數據單位是 文件 ，它的目的是對磁碟上的文件進行組織管理，那組織的方式不同,就會形成不同的文件系統。
Linux最經典的一句話是:「一切皆文件」,不僅普通的文件和目錄，就連塊設備、管道、socket 等，也都是統一交給文件系統管理的。
Linux文件系統會為每個文件分配兩個數據結構: 索引節點(index node) 和 目錄項(directory entry) ，它們主要用來記錄文件的元信息和目錄層次結構。
●索引節點，也就是inode, 用來記錄文件的元信息，比如inode編號、文件大小訪問許可權、創建時間、修改時間、 數據在磁碟的位置 等等。 索引節點是文件的唯一標識 ,它們之間一一對應, 也同樣都會被 存儲在硬碟 中,所以索引節點同樣佔用磁碟空間。
●目錄項，也就是dentry, 用來記錄文件的名字、索引節點指針以及與其他目錄項的層級關聯關系。多個目錄項關聯起來，就會形成 目錄結構 ，但它與索引節點不同的是,目錄項是由內核維護的一個數據結構,不存放於磁碟，而是 緩存在內存 。
由於索引節點唯一標識一個文件，而目錄項記錄著文件的名，所以目錄項和索引節點的關系是多對一,也就是說，一個文件可以有多個別字。比如，硬鏈接的實現就是多個目錄項中的索引節點指向同一個文件。
注意，目錄也是文件，也是用索引節點唯一標識，和普通文件不同的是，普通文件在磁碟裡面保存的是文件數據，而目錄文件在磁碟裡面保存子目錄或文件。
（PS：目錄項和目錄不是一個東西！你也不是一個東西（^_=）， 雖然名字很相近，但目錄是個文件。持久化存儲在磁碟,而目錄項是內核一個數據結構,緩存在內存。
如果查詢目錄頻繁從磁碟讀，效率會很低，所以內核會把已經讀過的目錄用目錄項這個數據結構緩存在內存，下次再次讀到相同的目錄時，只需從內存讀就可以,大大提高了 文件系統的效率。
目錄項這個數據結構不只是表示目錄，也是可以表示文件的。）
磁碟讀寫的最小單位是 扇區 ，扇區的大小隻有512B大小，很明顯，如果每次讀寫都以這么小為單位，那這讀寫的效率會非常低。
所以，文件系統把多個扇區組成了一個 邏輯塊 ，每次讀寫的最小單位就是邏輯塊(數據塊) , Linux中的邏輯塊大小為4KB,也就是一次性讀寫 8個扇區,這將大大提高了磁碟的讀寫的效率。
以上就是索引節點、目錄項以及文件數據的關系，下面這個圖就很好的展示了它們之間的關系:
索引節點是存儲在硬碟上的數據，那麼為了加速文件的訪問，通常會把索引節點載入到內存中。
另外，磁碟進行格式化的時候，會被分成三個存儲區域，分別是超級塊、索引節點區和數據塊區。
●超級塊,用來存儲文件系統的詳細信息，比如塊個數、塊大小、空閑塊等等。
●索引節點區,用來存儲索引節點;
●數據塊區，用來存儲文件或目錄數據;
我們不可能把超級塊和索引節點區全部載入到內存,這樣內存肯定撐不住，所以只有當需要使用的時候，才將其載入進內存，它們載入進內存的時機是不同的.
●超級塊:當文件系統掛載時進入內存;
●索引節點區:當文件被訪問時進入內存;
文件系統的種類眾多，而操作系統希望 對用戶提供一個統一的介面 ，於是在用戶層與文件系統層引入了中間層，這個中間層就稱為 虛擬文件系統(Virtual File System, VFS) 。
VFS定義了一組所有文件系統都支持的數據結構和標准介面,這樣程序員不需要了解文件系統的工作原理，只需要了解VFS提供的統一介面即可。
在Linux文件系統中，用戶空間、系統調用、虛擬機文件系統、緩存、文件系統以及存儲之間的關系如下圖:
Linux支持的文件系統也不少，根據存儲位置的不同，可以把文件系統分為三類:
●磁碟的文件系統，它是直接把數據存儲在磁碟中,比如Ext 2/3/4. XFS 等都是這類文件系統。
●內存的文件系統，這類文件系統的數據不是存儲在硬碟的,而是佔用內存空間，我們經常用到的/proc 和/sys文件系統都屬於這一類,讀寫這類文件,實際上是讀寫內核中相關的數據。
●網路的文件系統,用來訪問其他計算機主機數據的文件系統，比如NFS. SMB等等。
文件系統首先要先掛載到某個目錄才可以正常使用，比如Linux系統在啟動時,會把文件系統掛載到根目錄。
在操作系統的輔助之下，磁碟中的數據在計算機中都會呈現為易讀的形式，並且我們不需要關心數據到底是如何存放在磁碟中,存放在磁碟的哪個地方等等問題，這些全部都是由操作系統完成的。
那麼，文件數據在磁碟中究竟是怎麼樣的呢?我們來一探究竟!
磁碟中的存儲單元會被劃分為一個個的「 塊 」，也被稱為 扇區 ,扇區的大小一般都為512byte.這說明即使一塊數據不足512byte,那麼它也要佔用512byte的磁碟空間。
而幾乎所有的文件系統都會把文件分割成固定大小的塊來存儲，通常一個塊的大小為4K。如果磁碟中的扇區為512byte,而文件系統的塊大小為4K,那麼文件系統的存儲單元就為8個扇區。這也是前面提到的一個問題，文件大小和佔用空間之間有什麼區別?文件大小是文件實際的大小，而佔用空間則是因為即使它的實際大小沒有達到那麼大,但是這部分空間實際也被佔用，其他文件數據無法使用這部分的空間。所以我們 寫入1byte的數據到文本中,但是它佔用的空間也會是4K。
這里要注意在Windows下的NTFS文件系統中，如果一開始文件數據小於 1K,那麼則不會分配磁碟塊來存儲，而是存在一個文件表中。但是一旦文件數據大於1K,那麼不管以後文件的大小，都會分配以4K為單位的磁碟空間來存儲。
與內存管理一樣,為了方便對磁碟的管理,文件的邏輯地址也被分為一個個的文件塊。於是文件的邏輯地址就是(邏輯塊號，塊內地址)。用戶通過邏輯地址來操作文件,操作系統負責完成邏輯地址與物理地址的映射。
不同的文件系統為文件分配磁碟空間會有不同的方式，這些方式各自都有優缺點。
連續分配要求每個文件在磁碟上有一組連續的塊，該分配方式較為簡單。
通過上圖可以看到，文件的邏輯塊號的順序是與物理塊號相同的,這樣就可以實現隨機存取了，只要知道了第一個邏輯塊的物理地址, 那麼就可以快速訪問到其他邏輯塊的物理地址。那麼操作系統如何完成邏輯塊與物理塊之間的映射呢?實際上,文件都是存放在目錄下的，而目錄是一種有結構文件, 所以在文件目錄的記錄中會存放目錄下所有文件的信息，每一個文件或者目錄都是一個記錄。 而這些信息就包括文件的起始塊號和佔有塊號的數量。
那麼操作系統如何完成邏輯塊與物理塊之間的映射呢? (邏輯塊號, 塊內地址) -> (物理塊號, 塊內地址)，只需要知道邏輯塊號對應的物理塊號即可,塊內地址不變。
用戶訪問一個文件的內容,操作系統通過文件的標識符找到目錄項FCB, 物理塊號=起始塊號+邏輯塊號。 當然，還需要檢查邏輯塊號是否合法,是否超過長度等。因為可以根據邏輯塊號直接算出物理塊號，所以連續分配支持 順序訪問和隨機訪問 。
因為讀/寫文件是需要移動磁頭的，如果訪問兩個相隔很遠的磁碟塊,移動磁頭的時間就會變長。使用連續分配來作為文件的分配方式，會使文件的磁碟塊相鄰，所以文件的讀/寫速度最快。
連續空間存放的方式雖然讀寫效率高，但是有 磁碟空間碎片 和 文件長度不易擴展 的缺陷。
如下圖，如果文件B被刪除，磁碟上就留下一塊空缺，這時，如果新來的文件小於其中的一個空缺，我們就可以將其放在相應空缺里。但如果該文件的大小大於所
有的空缺，但卻小於空缺大小之和，則雖然磁碟上有足夠的空缺，但該文件還是不能存放。當然了，我們可以通過將現有文件進行挪動來騰出空間以容納新的文件,但是這個在磁碟挪動文件是非常耗時，所以這種方式不太現實。
另外一個缺陷是文件長度擴展不方便，例如上圖中的文件A要想擴大一下，需要更多的磁碟空間,唯一的辦法就只能是挪動的方式，前面也說了，這種方式效率是非常低的。
那麼有沒有更好的方式來解決上面的問題呢?答案當然有，既然連續空間存放的方式不太行，那麼我們就改變存放的方式，使用非連續空間存放方式來解決這些缺陷。
非連續空間存放方式分為 鏈表方式 和 索引方式 。
鏈式分配採取離散分配的方式，可以為文件分配離散的磁碟塊。它有兩種分配方式:顯示鏈接和隱式鏈接。
隱式鏈接是只目錄項中只會記錄文件所佔磁碟塊中的第一塊的地址和最後一塊磁碟塊的地址, 然後通過在每一個磁碟塊中存放一個指向下一 磁碟塊的指針， 從而可以根據指針找到下一塊磁碟塊。如果需要分配新的磁碟塊,則使用最後一塊磁碟塊中的指針指向新的磁碟塊,然後修改新的磁碟塊為最後的磁碟塊。
我們來思考一個問題, 採用隱式鏈接如何將實現邏輯塊號轉換為物理塊號呢?
用戶給出需要訪問的邏輯塊號i,操作系統需要找到所需訪問文件的目錄項FCB.從目錄項中可以知道文件的起始塊號，然後將邏輯塊號0的數據讀入內存,由此知道1號邏輯塊的物理塊號，然後再讀入1號邏輯塊的數據進內存，此次類推，最終可以找到用戶所需訪問的邏輯塊號i。訪問邏輯塊號i,總共需要i+ 1次磁碟1/0操作。
得出結論: 隱式鏈接分配只能順序訪問，不支持隨機訪問，查找效率低 。
我們來思考另外一個問題，採用隱式鏈接是否方便文件拓展?
我們知道目錄項中存有結束塊號的物理地址，所以我們如果要拓展文件，只需要將新分配的磁碟塊掛載到結束塊號的後面即可，修改結束塊號的指針指向新分配的磁碟塊，然後修改目錄項。
得出結論: 隱式鏈接分配很方便文件拓展。所有空閑磁碟塊都可以被利用到，無碎片問題，存儲利用率高。
顯示鏈接是把用於鏈接各個物理塊的指針顯式地存放在一張表中，該表稱為文件分配表(FAT, File Allocation Table)。
由於查找記錄的過程是在內存中進行的,因而不僅顯著地 提高了檢索速度 ，而且 大大減少了訪問磁碟的次數 。但也正是整個表都存放在內存中的關系，它的主要的缺點是 不適 用於大磁碟 。
比如，對於200GB的磁碟和1KB大小的塊，這張表需要有2億項，每一項對應於這2億個磁碟塊中的一個塊,每項如果需要4個位元組，那這張表要佔用800MB內存,很顯然FAT方案對於大磁碟而言不太合適。
一直都在，加油！（*゜Д゜）σ凸←自爆按鈕
鏈表的方式解決了連續分配的磁碟碎片和文件動態打展的問題，但是不能有效支持直接訪問(FAT除外) ,索引的方式可以解決這個問題。
索引的實現是為每個文件創建一個 索引數據塊 ，裡面存放的 是指向文件數據塊的指針列表 ,說白了就像書的目錄一樣,要找哪個章節的內容,看目錄查就可以。
另外， 文件頭需要包含指向索引數據塊的指針 ,這樣就可以通過文件頭知道索引數據塊的位置，再通過索弓|數據塊里的索引信息找到對應的數據塊。
創建文件時，索引塊的所有指針都設為空。當首次寫入第i塊時，先從空閑空間中取得一個塊， 再將其地址寫到索引塊的第i個條目。
索引的方式優點在於:
●文件的創建、增大、縮小很方便;
●不會有碎片的問題;
●支持順序讀寫和隨機讀寫;
由於索引數據也是存放在磁碟塊的，如果文件很小，明明只需一塊就可以存放的下，但還是需要額外分配一塊來存放索引數據，所以缺陷之一就是存儲索引帶來的開銷。
如果文件很大，大到一個索引數據塊放不下索引信息，這時又要如何處理大文件的存放呢?我們可以通過組合的方式，來處理大文件的存儲。
先來看看 鏈表+索引 的組合，這種組合稱為 鏈式索引塊 ，它的實現方式是在 索引數據塊留出一個存放下一個索引數據塊的指針 ，於是當一個索引數據塊的索引信息用完了，就可以通過指針的方式，找到下一個索引數據塊的信息。那這種方式也會出現前面提到的鏈表方式的問題，萬一某個指針損壞了，後面的數據也就會無法讀取了。
還有另外一種組合方式是 索引+索引 的方式，這種組合稱為多級索引塊，實現方式是通過一個索引塊來存放多個索引數據塊,一層套一層索引， 像極了俄羅斯套娃是吧๑乛◡乛๑
前面說到的文件的存儲是針對已經被佔用的數據塊組織和管理，接下來的問題是，如果我要保存一個數據塊, 我應該放在硬碟上的哪個位置呢?難道需要將所有的塊掃描一遍，找個空的地方隨便放嗎?
那這種方式效率就太低了，所以針對磁碟的空閑空間也是要引入管理的機制，接下來介紹幾種常見的方法:
●空閑表法
●空閑鏈表法
●點陣圖法
空閑表法
空閑表法就是為所有空閑空間建立一張表，表內容包括空閑區的第一個塊號和該空閑區的塊個數，注意，這個方式是連續分配的。如下圖:
當請求分配磁碟空間時，系統依次掃描空閑表裡的內容，直到找到一個合適的空閑區域為止。當用戶撤銷一個文件時，系統回收文件空間。這時，也需順序掃描空閑表,尋找一個空閑表條目並將釋放空間的第一個物理塊號及它佔用的塊數填到這個條目中。
這種方法僅當有少量的空閑區時才有較好的效果。因為，如果存儲空間中有著大量的小的空閑區,則空閑表變得很大,這樣查詢效率會很低。另外，這種分配技術適用於建立連續文件。
空閑鏈表法
我們也可以使用鏈表的方式來管理空閑空間，每一個空閑塊里有一個指針指向下一個空閑塊，這樣也能很方便的找到空閑塊並管理起來。如下圖：
當創建文件需要一塊或幾塊時，就從鏈頭上依次取下一塊或幾塊。反之，當回收空間時，把這些空閑塊依次接到鏈頭上。
這種技術只要在主存中保存一個指針, 令它指向第一個空閑塊。其特點是簡單,但不能隨機訪問，工作效率低，因為每當在鏈上增加或移動空閑塊時需要做很多1/0操作,同時數據塊的指針消耗了一定的存儲空間。
空閑表法和空閑鏈表法都不適合用於大型文件系統，因為這會使空閑表或空閑鏈表太大。
點陣圖法
點陣圖是利用二進制的一位來表示磁碟中一個盤塊的使用情況，磁碟上所有的盤塊都有一個二進制位與之對應。
當值為0時，表示對應的盤塊空閑，值為1時，表示對應的盤塊已分配。它形式如下:
在Linux文件系統就採用了點陣圖的方式來管理空閑空間,不僅用於數據空閑塊的管理,還用於inode空閑塊的管理，因為inode也是存儲在磁碟的，自然也要有對其管理。
前面提到Linux是用點陣圖的方式管理空閑空間，用戶在創建一個新文件時， Linux 內核會通過inode的點陣圖找到空閑可用的inode,並進行分配。要存儲數據時，會通過塊的點陣圖找到空閑的塊，並分配，但仔細計算一下還是有問題的。
數據塊的點陣圖是放在磁碟塊里的，假設是放在一個塊里,一個塊4K,每位表示一個數據塊,共可以表示4 * 1024 * 8 = 2^15個空閑塊,由於1個數據塊是4K大小，那麼最大可以表示的空間為2^15 * 4 * 1024 = 2^27個byte,也就是128M。
也就是說按照上面的結構，如果採用（一個塊的點陣圖+ 一系列的塊），外加一（個塊的inode的點陣圖+一系列的inode）的結構能表示的最大空間也就128M,
這太少了，現在很多文件都比這個大。
在Linux文件系統，把這個結構稱為一個 塊組 ，那麼有N多的塊組,就能夠表示N大的文件。
最終,整個文件系統格式就是下面這個樣子。
最前面的第一個塊是引導塊,在系統啟動時用於啟用引導，接著後面就是一個一個連續的塊組了,塊組的內容如下:
● 超級塊 ,包含的是文件系統的重要信息，比如inode總個數、塊總個數、每個塊組的inode個數、每個塊組的塊個數等等。
● 塊組描述符 ,包含文件系統中各個塊組的狀態,比如塊組中空閑塊和inode的數目等，每個塊組都包含了文件系統中「所有塊組的組描述符信息」。
● 數據點陣圖和inode點陣圖 ，用於表示對應的數據塊或inode是空閑的，還是被使用中。
● inode 列表 ，包含了塊組中所有的inode, inode 用於保存文件系統中與各個文件和目錄相關的所有元數據。
● 數據塊 ，包含文件的有用數據。
你可以會發現每個塊組里有很多重復的信息，比如 超級塊和塊組描述符表，這兩個都是全局信息，而且非常的重要 ，這么做是有兩個原因:
●如果系統崩潰破壞了超級塊或塊組描述符,有關文件系統結構和內容的所有信息都會丟失。如果有冗餘的副本,該信息是可能恢復的。
●通過使文件和管理數據盡可能接近，減少了磁頭尋道和旋轉,這可以提高文件系統的性能。
不過，Ext2 的後續版本採用了稀疏技術。該做法是，超級塊和塊組描述符表不再存儲到文件系統的每個塊組中,而是只寫入到塊組0、塊組1和其他ID可以表示為3、5、7的冪的塊組中。
在前面，我們知道了一個普通文件是如何存儲的，但還有一個特殊的文件,經常用到的目錄，它是如何保存的呢?
基於Linux 一切切皆文件的設計思想，目錄其實也是個文件,你甚至可以通過vim打開它，它也有inode, inode 裡面也是指向一些塊。
和普通文件不同的是， 普通文件的塊裡面保存的是文件數據，而目錄文件的塊裡面保存的是目錄裡面一項一項的文件信息 。
在目錄文件的塊中，最簡單的保存格式就是 列表 ，就是一項一項地將目錄下的文件信息(如文件名、文件inode.文件類型等)列在表裡。
列表中每一項就代表該目錄下的文件的文件名和對應的inode,通過這個inode,就可以找到真正的文件。
通常，第一項是「則」，表示當前目錄,第二項是.，表示上一級目錄, 接下來就是一項一項的文件名和inode。
如果一個目錄有超級多的文件,我們要想在這個目錄下找文件,按照列表一項一項的找,效率就不高了。
於是，保存目錄的格式改成 哈希表 ，對文件名進行哈希計算,把哈希值保存起來,如果我們要查找一個目錄下面的文件名，可以通過名稱取哈希。如果哈希能夠匹配上,就說明這個文件的信息在相應的塊裡面。
Linux系統的ext文件系統就是採用了哈希表，來保存目錄的內容,這種方法的優點是查找非常迅速，插入和刪除也較簡單,不過需要一些預備措施來避免哈希沖突。
目錄查詢是通過在磁碟上反復搜索完成，需要不斷地進行/0操作,開銷較大。所以,為了減少/0操作,把當前使用的文件目錄緩存在內存，以後要使用該文件時只要在內存中操作，從而降低了磁碟操作次數,提高了文件系統的訪問速度。
感謝您的閱讀，希望您能攝取到知識！加油！沖沖沖！（發現光，追隨光，成為光，散發光！）我是程序員耶耶！有緣再見。<－biubiu－⊂(`ω´∩)
㈡ linux 文件系統 是什麼意思
文件系統是操作系統用於明確存儲設備（常見的是磁碟，也有基於NANDFlash的固態硬碟）或分區上的文件的方法和數據結構；
即在存儲設備上組織文件的方法。
操作系統中負責管理和存儲文件信息的軟體機構稱為文件管理系統，簡稱文件系統。
文件系統由三部分組成：文件系統的介面，對對象操縱和管理的軟體集合，對象及屬性。
從系統角度來看，文件系統是對文件存儲設備的空間進行組織和分配，負責文件存儲並對存入的文件進行保護和檢索的系統。
㈢ ext2exploder鎬庝箞淇鏀筶inux鐨勭郴緇熸枃浠
1.ext2鏂囦歡緋葷粺鏁翠綋甯冨矓
涓涓紓佺洏鍙浠ュ垝鍒嗘垚澶氫釜鍒嗗尯錛屾瘡涓鍒嗗尯蹇呴』鍏堢敤鏍煎紡鍖栧伐鍏鳳紙渚嬪傛煇縐峬kfs鍛戒護錛夋牸寮忓寲鎴愭煇縐嶆牸寮忕殑鏂囦歡緋葷粺錛岀劧鍚庢墠鑳藉瓨鍌ㄦ枃浠訛紝鏍煎紡鍖栫殑榪囩▼浼氬湪紓佺洏涓婂啓涓浜涚＄悊瀛樺偍甯冨矓鐨勪俊鎮銆備笅鍥炬槸涓涓紓佺洏鍒嗗尯鏍煎紡鍖栨垚ext2鏂囦歡緋葷粺鍚庣殑瀛樺偍甯冨矓銆
鏂囦歡緋葷粺涓瀛樺偍鐨勬渶灝忓崟浣嶆槸鍧楋紙Block錛夛紝涓涓鍧楃┒絝熷氬ぇ鏄鍦ㄦ牸寮忓寲鏃剁『瀹氱殑錛屼緥濡俶ke2fs鐨-b閫夐」鍙浠ヨ懼畾鍧楀ぇ灝忎負1024銆2048鎴4096瀛楄妭錛岃繖浜 blocks 琚鑱氬湪涓璧峰垎鎴愬嚑涓澶х殑 block group銆傛瘡涓 block group 涓鏈夊氬皯涓 block 鏄鍥哄畾鐨勩傝屼笂鍥句腑鍚鍔ㄥ潡錛圔oot Block錛夌殑澶у皬鏄紜瀹氱殑錛屽氨鏄1KB錛屽惎鍔ㄥ潡鏄鐢盤C鏍囧噯瑙勫畾鐨勶紝鐢ㄦ潵瀛樺偍紓佺洏鍒嗗尯淇℃伅鍜屽惎鍔ㄤ俊鎮錛屼換浣曟枃浠剁郴緇熼兘涓嶈兘浣跨敤鍚鍔ㄥ潡銆傚惎鍔ㄥ潡涔嬪悗鎵嶆槸ext2鏂囦歡緋葷粺鐨勫紑濮嬶紝ext2鏂囦歡緋葷粺灝嗘暣涓鍒嗗尯鍒掓垚鑻ュ共涓鍚屾牱澶у皬鐨勫潡緇勶紙Block Group錛夛紝姣忎釜鍧楃粍閮界敱浠ヤ笅閮ㄥ垎緇勬垚
1).瓚呯駭鍧楋紙Super Block錛
鎻忚堪鏁翠釜鍒嗗尯鐨勬枃浠剁郴緇熶俊鎮錛屼緥濡傚潡澶у皬銆佹枃浠剁郴緇熺増鏈鍙楓佷笂嬈mount鐨勬椂闂寸瓑絳夈傝秴綰у潡鍦ㄦ瘡涓鍧楃粍鐨勫紑澶撮兘鏈変竴浠芥嫹璐濄
2).鍧楃粍鎻忚堪絎﹁〃錛圙DT錛孏roup Descriptor Table)
鐢卞緢澶氬潡緇勬弿榪扮︾粍鎴愶紝鏁翠釜鍒嗗尯鍒嗘垚澶氬皯涓鍧楃粍灝卞瑰簲鏈夊氬皯涓鍧楃粍鎻忚堪絎︺傛瘡涓鍧楃粍鎻忚堪絎︼紙Group Descriptor錛夊瓨鍌ㄤ竴涓鍧楃粍鐨勬弿榪頒俊鎮錛屼緥濡傚湪榪欎釜鍧楃粍涓浠庡摢閲屽紑濮嬫槸inode琛錛屼粠鍝閲屽紑濮嬫槸鏁版嵁鍧楋紝絀洪棽鐨剗node鍜屾暟鎹鍧楄繕鏈夊氬皯涓絳夌瓑銆傚拰瓚呯駭鍧楃被浼礆紝鍧楃粍鎻忚堪絎﹁〃鍦ㄦ瘡涓鍧楃粍鐨勫紑澶翠篃閮芥湁涓浠芥嫹璐濓紝榪欎簺淇℃伅鏄闈炲父閲嶈佺殑錛屼竴鏃﹁秴綰у潡鎰忓栨崯鍧忓氨浼氫涪澶辨暣涓鍒嗗尯鐨勬暟鎹錛屼竴鏃﹀潡緇勬弿榪扮︽剰澶栨崯鍧忓氨浼氫涪澶辨暣涓鍧楃粍鐨勬暟鎹錛屽洜姝ゅ畠浠閮芥湁澶氫喚鎷瘋礉銆傞氬父鍐呮牳鍙鐢ㄥ埌絎0涓鍧楃粍涓鐨勬嫹璐濓紝褰撴墽琛宔2fsck媯鏌ユ枃浠剁郴緇熶竴鑷存ф椂錛岀0涓鍧楃粍涓鐨勮秴綰у潡鍜屽潡緇勬弿榪扮﹁〃灝變細鎷瘋礉鍒板叾瀹冨潡緇勶紝榪欐牱褰撶0涓鍧楃粍鐨勫紑澶存剰澶栨崯鍧忔椂灝卞彲浠ョ敤鍏跺畠鎷瘋礉鏉ユ仮澶嶏紝浠庤屽噺灝戞崯澶便
3).鍧椾綅鍥撅紙Block Bitmap錛
涓涓鍧楃粍涓鐨勫潡鏄榪欐牱鍒╃敤鐨勶細鏁版嵁鍧楀瓨鍌ㄦ墍鏈夋枃浠剁殑鏁版嵁錛屾瘮濡傛煇涓鍒嗗尯鐨勫潡澶у皬鏄1024瀛楄妭錛屾煇涓鏂囦歡鏄2049瀛楄妭錛岄偅涔堝氨闇瑕佷笁涓鏁版嵁鍧楁潵瀛橈紝鍗充嬌絎涓変釜鍧楀彧瀛樹簡涓涓瀛楄妭涔熼渶瑕佸崰鐢ㄤ竴涓鏁村潡錛涜秴綰у潡銆佸潡緇勬弿榪扮﹁〃銆佸潡浣嶅浘銆乮node浣嶅浘銆乮node琛ㄨ繖鍑犻儴鍒嗗瓨鍌ㄨュ潡緇勭殑鎻忚堪淇℃伅銆傞偅涔堝備綍鐭ラ亾鍝浜涘潡宸茬粡鐢ㄦ潵瀛樺偍鏂囦歡鏁版嵁鎴栧叾瀹冩弿榪頒俊鎮錛屽摢浜涘潡浠嶇劧絀洪棽鍙鐢ㄥ憿錛熷潡浣嶅浘灝辨槸鐢ㄦ潵鎻忚堪鏁翠釜鍧楃粍涓鍝浜涘潡宸茬敤鍝浜涘潡絀洪棽鐨勶紝瀹冩湰韜鍗犱竴涓鍧楋紝鍏朵腑鐨勬瘡涓猙it浠ｈ〃鏈鍧楃粍涓鐨勪竴涓鍧楋紝榪欎釜bit涓1琛ㄧず璇ュ潡宸茬敤錛岃繖涓猙it涓0琛ㄧず璇ュ潡絀洪棽鍙鐢ㄣ
涓轟粈涔堢敤df鍛戒護緇熻℃暣涓紓佺洏鐨勫凡鐢ㄧ┖闂撮潪甯稿揩鍛錛熷洜涓哄彧闇瑕佹煡鐪嬫瘡涓鍧楃粍鐨勫潡浣嶅浘鍗沖彲錛岃屼笉闇瑕佹悳閬嶆暣涓鍒嗗尯銆傜浉鍙嶏紝鐢╠u鍛戒護鏌ョ湅涓涓杈冨ぇ鐩褰曠殑宸茬敤絀洪棿灝遍潪甯告參錛屽洜涓轟笉鍙閬垮厤鍦拌佹悳閬嶆暣涓鐩褰曠殑鎵鏈夋枃浠躲
涓庢ょ浉鑱旂郴鐨勫彟涓涓闂棰樻槸錛氬湪鏍煎紡鍖栦竴涓鍒嗗尯鏃剁┒絝熶細鍒掑嚭澶氬皯涓鍧楃粍鍛錛熶富瑕佺殑闄愬埗鍦ㄤ簬鍧椾綅鍥炬湰韜蹇呴』鍙鍗犱竴涓鍧椼傜敤mke2fs鏍煎紡鍖栨椂榛樿ゅ潡澶у皬鏄1024瀛楄妭錛屽彲浠ョ敤-b鍙傛暟鎸囧畾鍧楀ぇ灝忥紝鐜板湪璁懼潡澶у皬鎸囧畾涓篵瀛楄妭錛岄偅涔堜竴涓鍧楀彲浠ユ湁8b涓猙it錛岃繖鏍峰ぇ灝忕殑涓涓鍧椾綅鍥懼氨鍙浠ヨ〃紺8b涓鍧楃殑鍗犵敤鎯呭喌錛屽洜姝や竴涓鍧楃粍鏈澶氬彲浠ユ湁8b涓鍧楋紝濡傛灉鏁翠釜鍒嗗尯鏈塻涓鍧楋紝閭ｄ箞灝卞彲浠ユ湁s/(8b)涓鍧楃粍銆傛牸寮忓寲鏃跺彲浠ョ敤-g鍙傛暟鎸囧畾涓涓鍧楃粍鏈夊氬皯涓鍧楋紝浣嗘槸閫氬父涓嶉渶瑕佹墜鍔ㄦ寚瀹氾紝mke2fs宸ュ叿浼氳＄畻鍑烘渶浼樼殑鏁板箋
4).inode浣嶅浘錛坕node Bitmap錛
鍜屽潡浣嶅浘綾諱技錛屾湰韜鍗犱竴涓鍧楋紝鍏朵腑姣忎釜bit琛ㄧず涓涓猧node鏄鍚︾┖闂插彲鐢
5).inode琛錛坕node Table錛
鎴戜滑鐭ラ亾錛屼竴涓鏂囦歡闄や簡鏁版嵁闇瑕佸瓨鍌ㄤ箣澶栵紝涓浜涙弿榪頒俊鎮涔熼渶瑕佸瓨鍌錛屼緥濡傛枃浠剁被鍨嬶紙甯歌勩佺洰褰曘佺﹀彿閾炬帴絳夛級錛屾潈闄愶紝鏂囦歡澶у皬錛屽壋寤/淇鏀/璁塊棶鏃墮棿絳夛紝涔熷氨鏄痩s -l鍛戒護鐪嬪埌鐨勯偅浜涗俊鎮錛岃繖浜涗俊鎮瀛樺湪inode涓鑰屼笉鏄鏁版嵁鍧椾腑銆傛瘡涓鏂囦歡閮芥湁涓涓猧node錛屼竴涓鍧楃粍涓鐨勬墍鏈塱node緇勬垚浜唅node琛ㄣ
inode琛ㄥ崰澶氬皯涓鍧楀湪鏍煎紡鍖栨椂灝辮佸喅瀹氬苟鍐欏叆鍧楃粍鎻忚堪絎︿腑錛宮ke2fs鏍煎紡鍖栧伐鍏風殑榛樿ょ瓥鐣ユ槸涓涓鍧楃粍鏈夊氬皯涓8KB灝卞垎閰嶅氬皯涓猧node銆傜敱浜庢暟鎹鍧楀崰浜嗘暣涓鍧楃粍鐨勭粷澶ч儴鍒嗭紝涔熷彲浠ヨ繎浼艱や負鏁版嵁鍧楁湁澶氬皯涓8KB灝卞垎閰嶅氬皯涓猧node錛屾崲鍙ヨ瘽璇達紝濡傛灉騫沖潎姣忎釜鏂囦歡鐨勫ぇ灝忔槸8KB錛屽綋鍒嗗尯瀛樻弧鐨勬椂鍊檌node琛ㄤ細寰楀埌姣旇緝鍏呭垎鐨勫埄鐢錛屾暟鎹鍧椾篃涓嶆氮璐廣傚傛灉榪欎釜鍒嗗尯瀛樼殑閮芥槸寰堝ぇ鐨勬枃浠訛紙姣斿傜數褰憋級錛屽垯鏁版嵁鍧楃敤瀹岀殑鏃跺檌node浼氭湁涓浜涙氮璐癸紝濡傛灉榪欎釜鍒嗗尯瀛樼殑閮芥槸寰堝皬鐨勬枃浠訛紙姣斿傛簮浠ｇ爜錛夛紝鍒欐湁鍙鑳芥暟鎹鍧楄繕娌＄敤瀹宨node灝卞凡緇忕敤瀹屼簡錛屾暟鎹鍧楀彲鑳芥湁寰堝ぇ鐨勬氮璐廣傚傛灉鐢ㄦ埛鍦ㄦ牸寮忓寲鏃惰兘澶熷硅繖涓鍒嗗尯浠ュ悗瑕佸瓨鍌ㄧ殑鏂囦歡澶у皬鍋氫竴涓棰勬祴錛屼篃鍙浠ョ敤mke2fs鐨-i鍙傛暟鎵嬪姩鎸囧畾姣忓氬皯涓瀛楄妭鍒嗛厤涓涓猧node銆
6).鏁版嵁鍧楋紙Data Block錛
鏍規嵁涓嶅悓鐨勬枃浠剁被鍨嬫湁浠ヤ笅鍑犵嶆儏鍐
瀵逛簬甯歌勬枃浠訛紝鏂囦歡鐨勬暟鎹瀛樺偍鍦ㄦ暟鎹鍧椾腑銆
瀵逛簬鐩褰曪紝璇ョ洰褰曚笅鐨勬墍鏈夋枃浠跺悕鍜岀洰褰曞悕瀛樺偍鍦ㄦ暟鎹鍧椾腑錛屾敞鎰忔枃浠跺悕淇濆瓨鍦ㄥ畠鎵鍦ㄧ洰褰曠殑鏁版嵁鍧椾腑錛岄櫎鏂囦歡鍚嶄箣澶栵紝ls -l鍛戒護鐪嬪埌鐨勫叾瀹冧俊鎮閮戒繚瀛樺湪璇ユ枃浠剁殑inode涓銆傛敞鎰忚繖涓姒傚康錛氱洰褰曚篃鏄涓縐嶆枃浠訛紝鏄涓縐嶇壒孌婄被鍨嬬殑鏂囦歡銆
瀵逛簬絎﹀彿閾炬帴錛屽傛灉鐩鏍囪礬寰勫悕杈冪煭鍒欑洿鎺ヤ繚瀛樺湪inode涓浠ヤ究鏇村揩鍦版煡鎵撅紝濡傛灉鐩鏍囪礬寰勫悕杈冮暱鍒欏垎閰嶄竴涓鏁版嵁鍧楁潵淇濆瓨銆
璁懼囨枃浠躲丗IFO鍜宻ocket絳夌壒孌婃枃浠舵病鏈夋暟鎹鍧楋紝璁懼囨枃浠剁殑涓昏懼囧彿鍜屾¤懼囧彿淇濆瓨鍦╥node涓銆
2.鏁版嵁鍧楀誨潃
濡傛灉涓涓鏂囦歡鏈夊氫釜鏁版嵁鍧楋紝榪欎簺鏁版嵁鍧楀緢鍙鑳戒笉鏄榪炵畫瀛樻斁鐨勶紝搴旇ュ備綍瀵誨潃鍒版瘡涓鍧楀憿錛熷疄闄呬笂錛屾牴鐩褰曠殑鏁版嵁鍧楁槸閫氳繃鍏秈node涓鐨勭儲寮曢」Blocks[0]鎵懼埌鐨勶紝浜嬪疄涓婏紝榪欐牱鐨勭儲寮曢」涓鍏辨湁15涓錛屼粠Blocks[0]鍒癇locks[14]錛屾瘡涓緔㈠紩欏瑰崰4瀛楄妭銆傚墠12涓緔㈠紩欏歸兘琛ㄧず鍧楃紪鍙鳳紝渚嬪備笂闈㈢殑渚嬪瓙涓瑽locks[0]瀛楁典繚瀛樼潃24錛屽氨琛ㄧず絎24涓鍧楁槸璇ユ枃浠剁殑鏁版嵁鍧楋紝濡傛灉鍧楀ぇ灝忔槸1KB錛岃繖鏍峰彲浠ヨ〃紺轟粠0瀛楄妭鍒12KB鐨勬枃浠躲傚傛灉鍓╀笅鐨勪笁涓緔㈠紩欏笲locks[12]鍒癇locks[14]涔熸槸榪欎箞鐢ㄧ殑錛屽氨鍙鑳借〃紺烘渶澶15KB鐨勬枃浠朵簡錛岃繖鏄榪滆繙涓嶅熺殑錛屼簨瀹炰笂錛屽墿涓嬬殑涓変釜緔㈠紩欏歸兘鏄闂存帴緔㈠紩銆
緔㈠紩欏笲locks[12]鎵鎸囧悜鐨勫潡騫墮潪鏁版嵁鍧楋紝鑰屾槸縐頒負闂存帴瀵誨潃鍧楋紙Indirect Block錛夛紝鍏朵腑瀛樻斁鐨勯兘鏄綾諱技Blocks[0]榪欑嶇儲寮曢」錛屽啀鐢辯儲寮曢」鎸囧悜鏁版嵁鍧椼傝懼潡澶у皬鏄痓錛岄偅涔堜竴涓闂存帴瀵誨潃鍧椾腑鍙浠ュ瓨鏀綽/4涓緔㈠紩欏癸紝鎸囧悜b/4涓鏁版嵁鍧椼傛墍浠ュ傛灉鎶夿locks[0]鍒癇locks[12]閮界敤涓婏紝鏈澶氬彲浠ヨ〃紺篵/4+12涓鏁版嵁鍧楋紝瀵逛簬鍧楀ぇ灝忔槸1K鐨勬儏鍐碉紝鏈澶у彲琛ㄧず268K鐨勬枃浠躲傚備笅鍥炬墍紺猴紝娉ㄦ剰鏂囦歡鐨勬暟鎹鍧楃紪鍙鋒槸浠0寮濮嬬殑錛孊locks[0]鎸囧悜絎0涓鏁版嵁鍧楋紝Blocks[11]鎸囧悜絎11涓鏁版嵁鍧楋紝Blocks[12]鎵鎸囧悜鐨勯棿鎺ュ誨潃鍧楃殑絎涓涓緔㈠紩欏規寚鍚戠12涓鏁版嵁鍧楋紝渚濇ょ被鎺ㄣ
浠庝笂鍥懼彲浠ョ湅鍑猴紝緔㈠紩欏笲locks[13]鎸囧悜涓ょ駭鐨勯棿鎺ュ誨潃鍧楋紝鏈澶氬彲琛ㄧず(b/4)2+b/4+12涓鏁版嵁鍧楋紝瀵逛簬1K鐨勫潡澶у皬鏈澶у彲琛ㄧず64.26MB鐨勬枃浠躲傜儲寮曢」Blocks[14]鎸囧悜涓夌駭鐨勯棿鎺ュ誨潃鍧楋紝鏈澶氬彲琛ㄧず(b/4)3+(b/4)2+b/4+12涓鏁版嵁鍧楋紝瀵逛簬1K鐨勫潡澶у皬鏈澶у彲琛ㄧず16.06GB鐨勬枃浠躲
鍙瑙侊紝榪欑嶅誨潃鏂瑰紡瀵逛簬璁塊棶涓嶈秴榪12涓鏁版嵁鍧楃殑灝忔枃浠舵槸闈炲父蹇鐨勶紝璁塊棶鏂囦歡涓鐨勪換鎰忔暟鎹鍙闇瑕佷袱嬈¤葷洏鎿嶄綔錛屼竴嬈¤籭node錛堜篃灝辨槸璇葷儲寮曢」錛変竴嬈¤繪暟鎹鍧椼傝岃塊棶澶ф枃浠朵腑鐨勬暟鎹鍒欓渶瑕佹渶澶氫簲嬈¤葷洏鎿嶄綔錛歩node銆佷竴綰ч棿鎺ュ誨潃鍧椼佷簩綰ч棿鎺ュ誨潃鍧椼佷笁綰ч棿鎺ュ誨潃鍧椼佹暟鎹鍧椼傚疄闄呬笂錛岀佺洏涓鐨剗node鍜屾暟鎹鍧楀線寰宸茬粡琚鍐呮牳緙撳瓨浜嗭紝璇誨ぇ鏂囦歡鐨勬晥鐜囦篃涓嶄細澶浣庛
3.鏂囦歡鍜岀洰褰曟搷浣滅殑緋葷粺鍑芥暟(榪欓噷闈㈢殑"(n)"搴旇ヨ〃紺哄弬鏁扮殑涓鏁)
1).stat(2)鍑芥暟璇誨彇鏂囦歡鐨剗node錛岀劧鍚庢妸inode涓鐨勫悇縐嶆枃浠跺睘鎬у～鍏ヤ竴涓猻truct stat緇撴瀯浣撲紶鍑虹粰璋冪敤鑰呫俿tat(1)鍛戒護鏄鍩轟簬stat鍑芥暟瀹炵幇鐨勩俿tat闇瑕佹牴鎹浼犲叆鐨勬枃浠惰礬寰勬壘鍒癷node錛屽亣璁句竴涓璺寰勬槸/opt/file錛屽垯鏌ユ壘鐨勯『搴忔槸錛
璇誨嚭inode琛ㄤ腑絎2欏癸紝涔熷氨鏄鏍圭洰褰曠殑inode錛屼粠涓鎵懼嚭鏍圭洰褰曟暟鎹鍧楃殑浣嶇疆
浠庢牴鐩褰曠殑鏁版嵁鍧椾腑鎵懼嚭鏂囦歡鍚嶄負opt鐨勮板綍錛屼粠璁板綍涓璇誨嚭瀹冪殑inode鍙
璇誨嚭opt鐩褰曠殑inode錛屼粠涓鎵懼嚭瀹冪殑鏁版嵁鍧楃殑浣嶇疆
浠巓pt鐩褰曠殑鏁版嵁鍧椾腑鎵懼嚭鏂囦歡鍚嶄負file鐨勮板綍錛屼粠璁板綍涓璇誨嚭瀹冪殑inode鍙
璇誨嚭file鏂囦歡鐨剗node
榪樻湁鍙﹀栦袱涓綾諱技stat鐨勫嚱鏁幫細fstat(2)鍑芥暟浼犲叆涓涓宸叉墦寮鐨勬枃浠舵弿榪扮︼紝浼犲嚭inode淇℃伅錛宭stat(2)鍑芥暟涔熸槸浼犲叆璺寰勪紶鍑篿node淇℃伅錛屼絾鏄鍜宻tat鍑芥暟鏈変竴鐐逛笉鍚岋紝褰撴枃浠舵槸涓涓絎﹀彿閾炬帴鏃訛紝stat(2)鍑芥暟浼犲嚭鐨勬槸瀹冩墍鎸囧悜鐨勭洰鏍囨枃浠剁殑inode錛岃宭stat鍑芥暟浼犲嚭鐨勫氨鏄絎﹀彿閾炬帴鏂囦歡鏈韜鐨剗node銆
2).access(2)鍑芥暟媯鏌ユ墽琛屽綋鍓嶈繘紼嬬殑鐢ㄦ埛鏄鍚︽湁鏉冮檺璁塊棶鏌愪釜鏂囦歡錛屼紶鍏ユ枃浠惰礬寰勫拰瑕佹墽琛岀殑璁塊棶鎿嶄綔錛堣/鍐/鎵ц岋級錛宎ccess鍑芥暟鍙栧嚭鏂囦歡inode涓鐨剆t_mode瀛楁碉紝姣旇緝涓涓嬭塊棶鏉冮檺錛岀劧鍚庤繑鍥0琛ㄧず鍏佽歌塊棶錛岃繑鍥-1琛ㄧず閿欒鎴栦笉鍏佽歌塊棶銆
3).chmod(2)鍜宖chmod(2)鍑芥暟鏀瑰彉鏂囦歡鐨勮塊棶鏉冮檺錛屼篃灝辨槸淇鏀筰node涓鐨剆t_mode瀛楁點傝繖涓や釜鍑芥暟鐨勫尯鍒綾諱技浜巗tat/fstat銆俢hmod(1)鍛戒護鏄鍩轟簬chmod鍑芥暟瀹炵幇鐨勩
4).chown(2)/fchown(2)/lchown(2)鏀瑰彉鏂囦歡鐨勬墍鏈夎呭拰緇勶紝涔熷氨鏄淇鏀筰node涓鐨刄ser鍜孏roup瀛楁碉紝鍙鏈夎秴綰х敤鎴鋒墠鑳芥ｇ『璋冪敤榪欏嚑涓鍑芥暟錛岃繖鍑犱釜鍑芥暟涔嬮棿鐨勫尯鍒綾諱技浜巗tat/fstat/lstat銆俢hown(1)鍛戒護鏄鍩轟簬chown鍑芥暟瀹炵幇鐨勩
5).utime(2)鍑芥暟鏀瑰彉鏂囦歡鐨勮塊棶鏃墮棿鍜屼慨鏀規椂闂達紝涔熷氨鏄淇鏀筰node涓鐨刟time鍜宮time瀛楁點倀ouch(1)鍛戒護鏄鍩轟簬utime鍑芥暟瀹炵幇鐨勩
6).truncate(2)鍜宖truncate(2)鍑芥暟鎶婃枃浠舵埅鏂鍒版煇涓闀垮害錛屽傛灉鏂扮殑闀垮害姣斿師鏉ョ殑闀垮害鐭錛屽垯鍚庨潰鐨勬暟鎹琚鎴鎺変簡錛屽傛灉鏂扮殑闀垮害姣斿師鏉ョ殑闀垮害闀匡紝鍒欏悗闈㈠氬嚭鏉ョ殑閮ㄥ垎鐢0濉鍏咃紝榪欓渶瑕佷慨鏀筰node涓鐨凚locks緔㈠紩欏逛互鍙婂潡浣嶅浘涓鐩稿簲鐨刡it銆傝繖涓や釜鍑芥暟鐨勫尯鍒綾諱技浜巗tat/fstat銆
7).link(2)鍑芥暟鍒涘緩紜閾炬帴錛屽叾鍘熺悊鏄鍦ㄧ洰褰曠殑鏁版嵁鍧椾腑娣誨姞涓鏉℃柊璁板綍錛屽叾涓鐨剗node鍙峰瓧孌靛拰鍘熸枃浠剁浉鍚屻俿ymlink(2)鍑芥暟鍒涘緩涓涓絎﹀彿閾炬帴錛岃繖闇瑕佸壋寤轟竴涓鏂扮殑inode錛屽叾涓璼t_mode瀛楁電殑鏂囦歡綾誨瀷鏄絎﹀彿閾炬帴錛屽師鏂囦歡鐨勮礬寰勪繚瀛樺湪inode涓鎴栬呭垎閰嶄竴涓鏁版嵁鍧楁潵淇濆瓨銆俵n(1)鍛戒護鏄鍩轟簬link鍜宻ymlink鍑芥暟瀹炵幇鐨勩
8).unlink(2)鍑芥暟鍒犻櫎涓涓閾炬帴銆傚傛灉鏄絎﹀彿閾炬帴鍒欓噴鏀捐繖涓絎﹀彿閾炬帴鐨剗node鍜屾暟鎹鍧楋紝娓呴櫎inode浣嶅浘鍜屽潡浣嶅浘涓鐩稿簲鐨勪綅銆傚傛灉鏄紜閾炬帴鍒欎粠鐩褰曠殑鏁版嵁鍧椾腑娓呴櫎涓鏉℃枃浠跺悕璁板綍錛屽傛灉褰撳墠鏂囦歡鐨勭‖閾炬帴鏁板凡緇忔槸1浜嗚繕瑕佸垹闄ゅ畠錛屽氨鍚屾椂閲婃斁瀹冪殑inode鍜屾暟鎹鍧楋紝娓呴櫎inode浣嶅浘鍜屽潡浣嶅浘涓鐩稿簲鐨勪綅錛岃繖鏍峰氨鐪熺殑鍒犻櫎鏂囦歡浜嗐倁nlink(1)鍛戒護鍜宺m(1)鍛戒護鏄鍩轟簬unlink鍑芥暟瀹炵幇鐨勩
9).rename(2)鍑芥暟鏀瑰彉鏂囦歡鍚嶏紝闇瑕佷慨鏀圭洰褰曟暟鎹鍧椾腑鐨勬枃浠跺悕璁板綍錛屽傛灉鍘熸枃浠跺悕鍜屾柊鏂囦歡鍚嶄笉鍦ㄤ竴涓鐩褰曚笅鍒欓渶瑕佷粠鍘熺洰褰曟暟鎹鍧椾腑娓呴櫎涓鏉¤板綍鐒跺悗娣誨姞鍒版柊鐩褰曠殑鏁版嵁鍧椾腑銆俶v(1)鍛戒護鏄鍩轟簬rename鍑芥暟瀹炵幇鐨勶紝鍥犳ゅ湪鍚屼竴鍒嗗尯鐨勪笉鍚岀洰褰曚腑縐誨姩鏂囦歡騫朵笉闇瑕佸嶅埗鍜屽垹闄ゆ枃浠剁殑inode鍜屾暟鎹鍧楋紝鍙闇瑕佷竴涓鏀瑰悕鎿嶄綔錛屽嵆浣胯佺Щ鍔ㄦ暣涓鐩褰曪紝榪欎釜鐩褰曚笅鏈夊緢澶氬瓙鐩褰曞拰鏂囦歡涔熻侀殢鐫涓璧風Щ鍔錛岀Щ鍔ㄦ搷浣滀篃鍙鏄瀵歸《綰х洰褰曠殑鏀瑰悕鎿嶄綔錛屽緢蹇灝辮兘瀹屾垚銆備絾鏄錛屽傛灉鍦ㄤ笉鍚岀殑鍒嗗尯涔嬮棿縐誨姩鏂囦歡灝卞繀欏誨嶅埗鍜屽垹闄inode鍜屾暟鎹鍧楋紝濡傛灉瑕佺Щ鍔ㄦ暣涓鐩褰曪紝鎵鏈夊瓙鐩褰曞拰鏂囦歡閮借佸嶅埗鍒犻櫎錛岃繖灝卞緢鎱浜嗐
10)readlink(2)鍑芥暟璇誨彇涓涓絎﹀彿閾炬帴鎵鎸囧悜鐨勭洰鏍囪礬寰勶紝鍏跺師鐞嗘槸浠庣﹀彿閾炬帴鐨剗node鎴栨暟鎹鍧椾腑璇誨嚭淇濆瓨鐨勬暟鎹錛岃繖灝辨槸鐩鏍囪礬寰勩
11).mkdir(2)鍑芥暟鍒涘緩鏂扮殑鐩褰曪紝瑕佸仛鐨勬搷浣滄槸鍦ㄥ畠鐨勭埗鐩褰曟暟鎹鍧椾腑娣誨姞涓鏉¤板綍錛岀劧鍚庡垎閰嶆柊鐨剗node鍜屾暟鎹鍧楋紝inode鐨剆t_mode瀛楁電殑鏂囦歡綾誨瀷鏄鐩褰曪紝鍦ㄦ暟鎹鍧椾腑濉涓や釜璁板綍錛屽垎鍒鏄.鍜..錛岀敱浜..琛ㄧず鐖剁洰褰曪紝鍥犳ょ埗鐩褰曠殑紜閾炬帴鏁拌佸姞1銆俶kdir(1)鍛戒護鏄鍩轟簬mkdir鍑芥暟瀹炵幇鐨勩
12).rmdir(2)鍑芥暟鍒犻櫎涓涓鐩褰曪紝榪欎釜鐩褰曞繀欏繪槸絀虹殑錛堝彧鍖呭惈.鍜..錛夋墠鑳藉垹闄わ紝瑕佸仛鐨勬搷浣滄槸閲婃斁瀹冪殑inode鍜屾暟鎹鍧楋紝娓呴櫎inode浣嶅浘鍜屽潡浣嶅浘涓鐩稿簲鐨勪綅錛屾竻闄ょ埗鐩褰曟暟鎹鍧椾腑鐨勮板綍錛岀埗鐩褰曠殑紜閾炬帴鏁拌佸噺1銆俽mdir(1)鍛戒護鏄鍩轟簬rmdir鍑芥暟瀹炵幇鐨勩
13).opendir(3)/readdir(3)/closedir(3)鐢ㄤ簬閬嶅巻鐩褰曟暟鎹鍧椾腑鐨勮板綍銆俹pendir鎵撳紑涓涓鐩褰曪紝榪斿洖涓涓狣IR *鎸囬拡浠ｈ〃榪欎釜鐩褰曪紝瀹冩槸涓涓綾諱技FILE *鎸囬拡鐨勫彞鏌勶紝closedir鐢ㄤ簬鍏抽棴榪欎釜鍙ユ焺錛屾妸DIR *鎸囬拡浼犵粰readdir璇誨彇鐩褰曟暟鎹鍧椾腑鐨勮板綍錛屾瘡嬈¤繑鍥炰竴涓鎸囧悜struct dirent鐨勬寚閽堬紝鍙嶅嶈誨氨鍙浠ラ亶鍘嗘墍鏈夎板綍錛屾墍鏈夎板綍閬嶅巻瀹屼箣鍚巖eaddir榪斿洖NULL
㈣ Linux中的/目錄在哪
1 通常一個 filesystem 的最頂層 inode 號碼會由 2 號開始
2 每個文件系統裡面有一張inode表 記錄當前文件系統中的所有目錄和文件,包 括 2 號的 / 也在裡面
系統查找文件時,首先去找
/ 掛載點所在分區的那個文件系統中的inode 表中的2號結點.
比如：你分區為:
分區 掛載點
/dev/hda1 /boot ---這個掛boot目錄
/dev/hda2 / ---這個掛/ 目錄
/dev/hda3 /u ---這個掛/u目錄
以上每一個分區都是一個獨立的文件系統.它就會跑去 /dev/hda2這個分區
發現這個文件系統裡面有以下內容:
inode table (inode表)
Superblock (超級區塊)
Filesystem Description (文件系統描述說明)
block bitmap (區塊對照表,就是描述哪個塊空閑，哪個正在被用)
inode bitmap (inode 對照表,描述哪個inode空，哪個被用)
data block (數據塊資料,存真正的文件數據)
又發現inode table 內容如下:
1 文件存取許可權 創建時間 修改時間 ....對應的block
2 文件存取許可權 創建時間 修改時間 ....對應的block
3 文件存取許可權 創建時間 修改時間 ....對應的block
4 文件存取許可權 創建時間 修改時間 ....對應的block
它就會很聰明地讀 inode號為2 的 inode 這個就是 /
然後讀它的 block 裡面的資料,發現block 是一張表,資料如下:
inode號 文件名
4 etc
5 service
... .....
假如要讀 etc 它就會讀etc 對應的 inode 號 4
再拿4去上面那張表找4的數據塊block...如此找下去.
當找到一個真正的文件時,發現是要的東西了.
這樣說明白沒有.