硬盤分區及Linux文件系統

1. 硬盤物理結構

 

硬盤物理上主要分爲：

1. 盤片
   1. 磁道
   2. 扇區
2. 機械臂
3. 磁頭
4. 主軸

 

磁道：

當硬盤盤片旋轉時，磁頭若固定在一個位置上，則磁頭會在盤片表面劃出一個圓形軌跡，這些圓形軌跡就叫作磁道。以盤片中心爲圓心，由此能夠劃分出不少磁道來， 這些磁道用肉眼是根本看不到的，由於它們僅 是盤面上以特殊方式磁化了的一些磁化區，硬盤上的信息即是沿着這樣的軌道存放的，盤片上的磁道由外向內依次從「0」開始進行編號。

 

柱面：

因爲硬盤能夠由不少盤片組成，不一樣盤片的相同磁道就組成了柱面(cylinder)，如第一個圖片。

磁頭：

假設有N個盤片組成的硬盤，那麼有2N個盤面(一個盤片有2面)，那麼磁頭也就有2N個，即每一個盤面有一個磁頭。

扇區：

早期的硬盤盤片的盤面以圓心開始向外放射狀將磁道分割成等分的弧段，這些弧段即是硬盤的扇區。每一個扇區通常規定大小爲512byte，這裏你們應該比較疑惑，外圈周長很明顯比內圈要長，怎麼可能每一個扇區都是512byte?其實答案早期硬盤外圈存儲比內圈存儲密度低一些，因此外圈很長可是仍然只能存儲512byte，所以若是咱們知道了柱面數(磁道數) Cylinders、磁頭數Heads、扇區數Sectors，基本上硬盤的容量咱們可以計算出來 硬盤總容量= Cylinders * Heads * Sectors * 512byte。可是因爲早期硬盤外圈密度低，致使盤片利用率不高，如今的硬盤盤片則採用內外存儲密度一致的方式，每一個磁道都劃分紅以512byte大小的弧段，這樣也形成了內外磁道上扇區數量會不同，外圈上的扇區數要多於內圈扇區數。

 

磁盤尋址方式：

硬盤存取、讀取數據，首先要作的就是尋址，即定位到數據所在的物理地址，在硬盤上就要找到對應的柱面、磁頭以及對應的扇區，那麼怎麼尋址呢？   有兩種方式：CHS和LBA

 

2. 磁盤分區

通常使用硬盤，首先會對硬盤進行分區，而後對分區使用某個文件系統格式（NTFS、FAT、ext2/ext3/ext4）進行分區格式化，而後才能正常使用。

柱面是分區的最小單元，即分區是某個柱面號開始到某個柱面號結束的。

 

 

 如圖，柱面1~200能夠分爲一個區，柱面201~500再劃分爲一個區，501~1000再劃分爲一個區，以此類推。柱面0沒有在任何分區裏面，爲什麼？　　

前面說到硬盤從外圈(柱面0)到內圈扇區是依次編號，看似各個扇區沒有什麼區別，可是這裏硬盤的柱面0的第一個扇區(邏輯扇區0，CHS表示應該是0/0/1)倒是最重要的，由於硬盤的第一個扇區記錄了整個硬盤的重要信息，第一個扇區(512個字節)主要記錄了兩部分：

 （1）MBR（Master Boot Record）：主引導程序就放在這裏，主引導程序是引導操做系統的一個程序，可是這部分只佔 446 字節

 （2）DPT（Disk Partition table）：硬盤分區表也在這裏，分區表就是用來記錄硬盤的分區狀況的，例如c盤是1~200柱面，d盤是201~500柱面，分區表總共只佔64字節，能夠看出，分區其實很簡單，就是在這個表裏面修改一下記錄就從新分區了，可是因爲只有64字節，而一條記錄就要佔用16字節，這個分區表最多隻能記錄4個分區信息，爲了繼續分出更多分區來，引入了擴展分區的概念，也就是說，在這4個分區中，可使用其中一條記錄來記錄擴展分區的信息，而後在擴展分區中再繼續劃分邏輯分區，而邏輯分區的分區記錄則記錄在擴展分區的第一個扇區中，如此則能夠像鏈表同樣劃分出不少分區來。可是請注意，一個分區表中能夠有1~4條主分區，可是最多隻能有1個擴展分區。

 　　舉例，主分區能夠是P1:1~200，擴展分區P2: 201~1400，擴展分區開始的第一個扇區能夠用來記錄擴展分區中劃分出來的邏輯分區。

 

3. 理解 Linux 的 inode / block / superblock

磁盤分區完畢後還須要進行格式化(format)，以後操做系統纔可以使用這個文件系統。 爲何須要進行『格式化』呢？

這是由於每種操做系統所設定的文件屬性/權限並不相同， 爲了存放這些文件所需的數據，所以就須要將分區進行格式化，以成爲操做系統可以利用的『文件系統格式(filesystem)』。每種操做系統可以使用的文件系統並不相同。

傳統的磁盤與文件系統應用中，一個分區就是隻可以被格式化成爲一個文件系統，因此能夠說一個 filesystem 就是一個 partition。可是因爲新技術的利用，例如常聽到的 LVM 與軟件磁盤陣列(software raid)， 這些技術能夠將一個分區格式化爲多個文件系統(例如 LVM)，也可以將多個分區合成一個文件系統(LVM, RAID)！ 因此說，目前在格式化時已經再也不說成針對partition來格式化了， 一般稱呼一個可被掛載的數據爲一個文件系統而不是一個分區。

文件系統一般會將這兩部份的數據分別存放在不一樣的區塊，權限與屬性放置到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)

那有沒有其餘的慣用文件系統能夠比較一下啊？ 有的，那就是咱們慣用的隨身碟(閃存)，隨身碟使用的文件系統通常爲 FAT 格式。FAT 這種格式的文件系統並無 inode 存在，因此 FAT 沒有辦法將這個文件的全部 block 在一開始就讀取出來。每一個 block 號碼都記錄在前一個 block 當中， 他的讀取方式有點像底下這樣：

 

 

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

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

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

inode 的內容在記錄文件的權限與相關屬性，至於 block 區塊則是在記錄文件的實際內容。 並且文件系統一開始就將 inode 與 block 規劃好了，除非從新格式化(或者利用 resize2fs 等指令變動文件系統大小)，不然 inode 與 block 固定後就再也不變更。可是若是仔細考慮一下，若是個人文件系統高達數百 GB 時， 那麼將全部的 inode 與 block 統統放置在一塊兒將是很不智的決定，由於 inode 與 block 的數量太龐大，不容易管理。所以 文件系統在格式化的時候基本上是區分爲多個區塊羣組（block group）的，每一個區塊羣組都有獨立的 inode / block / superblock 系統。

感受上就好像咱們在當兵時，一個營裏面有分紅數個連，每一個連有本身的聯絡系統， 但最終都向營部回報連上最正確的信息通常！這樣分紅一羣羣的比較好管理啦！整個來講，文件系統格式化後有點像底下這樣：

 

 

在總體的規劃中，文件系統最前面有一個啓動扇區（boot sector），這個啓動扇區能夠安裝開機管理程序，這是個很是重要的設計，由於如此一來咱們就可以將不一樣的開機管理程序安裝到個別的文件系統最前端，而不用覆蓋整顆磁盤惟一的 MBR， 這樣也纔可以製做出多重引導的環境。

每個區塊羣組(block group)的六個主要內容說明：

data block （資源區塊）

data block 是用來放置文件內容數據的地方，在文件系統中所支持的block 大小有 1k, 2k, 4k 三種而已。在格式化時 block 的大小是固定了，且每一個 block 都是有編號，以方便 inode 的記錄不過要注意的是，因爲 block 大小的差別，會致使該文件系統可以支持的最大磁盤容量與最大單一文件容量並不相同。 由於 block 大小而產生的 文件系統限制以下：

 

 

 

block 基本限制以下：

1. block 的大小與數量在格式化完就不能再改變了；
2. 每一個 block 內最多隻可以放置一個文件的數據；
3. 若是文件大於 block 的大小，則一個文件會佔用多個 block 數量；
4. 若文件小於 block，則該 block 的剩餘容量就不可以再被使用了（磁盤空間會浪費）

如上第四點所說，因爲每一個 block 僅能容納一個文件的數據而已，所以若是你的文件都很是小，可是你的 block 在格式化時卻選用最大的 4K 時，可能會產生一些容量的浪費喔！咱們以底下的一個
簡單例題來算一下空間的浪費吧！

 

 

什麼狀況會產生上述的情況呢？

例如 BBS 網站的數據啦！若是 BBS 上面的數據使用的是純文本文件來記載每篇留言， 而留言內容若是都寫上『如題』時，想想，是否就會產生不少小文件了呢？

好，既然大的 block 可能會產生較嚴重的磁盤容量浪費，那麼咱們是否就將 block 大小訂爲 1K 便可？ 這也不妥，由於若是 block 較小的話，那麼大型文件將會佔用數量更多的 block ，而 inode 也要記錄更多的 block 號碼，此時將可能致使文件系統不良的讀寫效能。

 

inode 是什麼

文件存儲在硬盤上，硬盤的最小存儲單位叫作 「扇區(Sector)」。每一個扇區儲存 512 字節（至關於 0.5KB）

操做系統讀取硬盤的時候，不會一個個扇區的讀取，這樣效率過低，而是一次性連續讀取多個扇區，即一次性讀取一個"塊"（block）。這種由多個扇區組成的"塊"，是文件存取的最小單位。"塊"的大小，最多見的是4KB，即連續八個 sector組成一個 block。

文件數據都儲存在"塊"中，那麼很顯然，還必須找到一個地方儲存文件的元信息，好比文件的建立者、文件的建立日期、文件的大小等等。這種儲存文件元信息的區域就叫作inode，中文譯名爲"索引節點"。

每個文件都有對應的inode，裏面包含了與該文件有關的一些信息。

 

inode 的內容

inode包含文件的元信息，具體來講有如下內容：

1. 文件的字節數
2. 文件擁有者的User ID
3. 文件的Group ID
4. 文件的讀、寫、執行權限
5. 文件的時間戳，共有三個：ctime指inode上一次變更的時間，mtime指文件內容上一次變更的時間，atime指文件上一次打開的時間。
6. 連接數，即有多少文件名指向這個inode
7. 文件數據block的位置

 

能夠用stat命令，查看某個文件的inode信息：

 

 

總之，除了文件名之外的全部文件信息，都存在inode之中。至於爲何沒有文件名，下文會有詳細解釋。

 

inode 大小

inode也會消耗硬盤空間，因此硬盤格式化的時候，操做系統自動將硬盤分紅兩個區域。一個是數據區，存放文件數據；另外一個是inode區（inode table），存放inode所包含的信息。

每一個inode節點的大小，通常是128字節或256字節。inode節點的總數，在格式化時就給定，通常是每1KB或每2KB就設置一個inode。假定在一塊1GB的硬盤中，每一個inode節點的大小爲128字節，每1KB就設置一個inode，那麼inode table的大小就會達到128MB，佔整塊硬盤的12.8%。

查看每一個硬盤分區的inode總數和已經使用的數量，可使用df命令。

 

 

 

查看每一個inode節點的大小，能夠用以下命令：

 

 

 

注意：

　　dumpe2fs 僅支持在 ext2/3/4 文件系統

　　若是是 xfs 須要使用 xfs_info 查看

 

 

 

inode 號碼

每一個inode都有一個號碼，操做系統用inode號碼來識別不一樣的文件。

這裏值得重複一遍，Unix/linux系統內部不使用文件名，而使用inode號碼來識別文件。對於系統來講，文件名只是inode號碼便於識別的別稱或者綽號。

表面上，用戶經過文件名，打開文件。實際上，系統內部這個過程分紅三步：

1. 系統找到這個文件名對應的inode號碼；
2. 經過inode號碼，獲取inode信息；
3. 根據inode信息，找到文件數據所在的block，讀出數據

 

使用ls -i命令，能夠看到文件名對應的inode號碼：

 

 

 

目錄文件

Unix/Linux系統中，目錄（directory）也是一種文件。打開目錄，實際上就是打開目錄文件。

目錄文件的結構很是簡單，就是一系列目錄項（dirent）的列表。每一個目錄項，由兩部分組成：所包含文件的文件名，以及該文件名對應的inode號碼。

ls命令只列出目錄文件中的全部文件名

ls -i命令列出整個目錄文件，即文件名和inode號碼：

 

 

 

若是要查看文件的詳細信息，就必須根據inode號碼，訪問inode節點，讀取信息。ls -l命令列出文件的詳細信息。

理解了上面這些知識，就能理解目錄的權限。目錄文件的讀權限（r）和寫權限（w），都是針對目錄文件自己（即不一樣用戶能以什麼權限訪問操做對該目錄文件，例如這裏不一樣用戶對tmp目錄文件（d能夠查出tmp是目錄文件，d表示directory，即目錄）分別爲rwxr-xr-x，第一組的三個字符，即rwx，表示文件擁有者用戶的對該文件的讀寫權限，第二組的三個字符，即r-x，表示文件擁有者用戶所在的用戶組裏的其餘用戶對該文件的讀寫權限，第三組的三個字符，即r-x，表示文件擁有者用戶所在的用戶組之外的用戶對該文件的讀寫權限。一個某個用戶下運行的進程訪問操做該目錄文件只能以該用戶所具備的對該目錄文件的權限進行操做）。因爲目錄文件內只有文件名和inode號碼，因此若是隻有讀權限，只能獲取文件名，沒法獲取其餘信息，由於其餘信息都儲存在inode節點中，而讀取inode節點內的信息須要目錄文件的執行權限（x）。

 

硬連接

通常狀況下，文件名和inode號碼是"一一對應"關係，每一個inode號碼對應一個文件名。可是，Unix/Linux系統容許，多個文件名指向同一個inode號碼。

這意味着，能夠用不一樣的文件名訪問一樣的內容；對文件內容進行修改，會影響到全部文件名；可是，刪除一個文件名，不影響另外一個文件名的訪問。這種狀況就被稱爲"硬連接"（hard link）。

ln 命令能夠建立硬連接：

ln 源文件 目標文件

 

 

運行上面這條命令之後，源文件與目標文件的inode號碼相同，都指向同一個inode。inode信息中有一項叫作"連接數"，記錄指向該inode的文件名總數，這時就會增長1。

反過來，刪除一個文件名，就會使得inode節點中的"連接數"減1。當這個值減到0，代表沒有文件名指向這個inode，系統就會回收這個inode號碼，以及其所對應block區域。

 

軟連接

除了硬連接之外，還有一種特殊狀況。

文件A 和 文件B 的 inode 號碼雖然不同，可是文件A 的內容是文件B 的路徑。讀取文件A時，系統會自動將訪問者導向文件B。所以，不管打開哪個文件，最終讀取的都是文件B。這時，文件A就稱爲文件B的"軟連接"（soft link）或者"符號連接（symbolic link）。

這意味着，文件A依賴於文件B而存在，若是刪除了文件B，打開文件A就會報錯："No such file or directory"。這是軟連接與硬連接最大的不一樣：文件A指向文件B的文件名，而不是文件B的inode號碼，文件B的inode"連接數"不會所以發生變化。

 

 

 

inode 的特殊做用

因爲inode號碼與文件名分離，這種機制致使了一些Unix/Linux系統特有的現象。

（1）有時，文件名包含特殊字符，沒法正常刪除。這時，直接刪除inode節點，就能起到刪除文件的做用。

（2）移動文件或重命名文件，只是改變文件名，不影響inode號碼。

（3）打開一個文件之後，系統就以inode號碼來識別這個文件，再也不考慮文件名。所以，一般來講，系統沒法從inode號碼得知文件名。

第3點使得軟件更新變得簡單，能夠在不關閉軟件的狀況下進行更新，不須要重啓。由於系統經過inode號碼，識別運行中的文件，不經過文件名。更新的時候，新版文件以一樣的文件名，生成一個新的inode，不會影響到運行中的文件。等到下一次運行這個軟件的時候，文件名就自動指向新版文件，舊版文件的inode則被回收。

 

總結：

1. 一個 inode 對應一個文件，而一個文件根據其大小，會佔用多塊 blocks；
2. 更爲準確的來講，一個文件只對應一個Inode。由於硬連接其實不是建立新文件，只是在Directory中寫入了新的對應關係而已；
3. 當刪除文件時，只是把 inode 標記爲可用，文件在block 中的內容是沒有被清除的，只有在有新的文件須要佔用block的時候，纔會被覆蓋。

 

文章參考自網絡 和 《鳥哥私房菜》

 

參考連接：

http://www.javashuo.com/article/p-vbcquzvf-kk.html
https://blog.csdn.net/Ohmyberry/article/details/80427492