當前位置：首頁 > 运维知识 > windows >内容正文

windows

OS- -文件系统(二)

發布時間：2024/4/11 windows 21 豆豆

生活随笔收集整理的這篇文章主要介紹了 OS- -文件系统(二) 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

OS- -文件系統(二)

文章目錄

OS- -文件系統(二)
- 一、文件系統的實現
- - 1.文件系統布局
  - - 引導塊
    - 超級塊
    - 空閑空間塊
    - 碎片
    - inode
  - 2.文件的實現
  - - 連續分配
    - 鏈表分配
    - 使用內存表進行鏈表分配
    - inode
  - 3.目錄的實現

一、文件系統的實現

在對文件有了基本認識之后，現在是時候把目光轉移到文件系統的實現上了。

之前用戶關心的一直都是文件是怎樣命名的、可以進行哪些操作、目錄樹是什么，如何找到正確的文件路徑等問題。

而設計人員關心的是文件和目錄是怎樣存儲的、磁盤空間是如何管理的、如何使文件系統得以流暢運行的問題，下面我們就來一起討論一下這些問題。

1.文件系統布局

文件系統存儲在磁盤中。大部分的磁盤能夠劃分出一到多個分區，叫做磁盤分區(disk partitioning)或者是磁盤分片(disk slicing)
每個分區都有獨立的文件系統，每塊分區的文件系統可以不同。磁盤的0號分區稱為主引導記錄(Master Boot Record, MBR),用來引導 (boot)計算機。
在MBR的結尾是分區表(partition table) ，每個分區表給出每個分區由開始到結束的地址。
系統管理員使用一個稱為分區編輯器的程序來創建，調整大小，刪除和操作分區。
這種方式的一個缺點是很難適當調整分區的大小，導致一個分區具有很多可用空間，而另一個分區幾乎完全被分配。

MBR可以用在DOS、Microsoft Windows和Linux操作系統中。
從2010年代中期開始，大多數新計算機都改用GUID分區表(GPT)分區方案。

下面是一個用GParted進行分區的磁盤，表中的分區都被認為是活動的(active)

引導塊

MBR做的第一件事就是確定活動分區,讀入它的第一個塊，稱為引導塊(boot block)并執行。引導塊中的程序將加載分區中的操作系統。
為了一致性，每個分區都會從引導塊開始，即使引導塊不包含操作系統。引導塊占據文件系統的前4096個字節，從磁盤上的字節偏移量0開始。引導塊可用于啟動操作系統。
在計算機中，引導就是啟動計算機的過程，它可以通過硬件(例如按下電源按鈕)或者軟件命令的方式來啟動。
開機后，電腦的CPU還不能執行指令，因為此時沒有軟件在主存中，所以一些軟件必須先被加載到內存中，然后才能讓CPU開始執行。也就是計算機開機后，首先會進行軟件的裝載過程。
重啟電腦的過程稱為重新引導(rebooting),從休眠或睡眠狀態返回計算機的過程不涉及啟動。
除了從引導塊開始之外，磁盤分區的布局是隨著文件系統的不同而變化的。

通常文件系統會包含一些屬性，如下：

超級塊

緊跟在引導塊后面的是超級塊(Superblock),超級塊的大小為4096字節，從磁盤上的字節偏移 4096開始。
超級塊包含文件系統的所有關鍵參數
?文件系統的大小
?文件系統中的數據塊數
?指示文件系統狀態的標志
?分配組大小

在計算機啟動或者文件系統首次使用時，超級塊會被讀入內存。

空閑空間塊

接著是文件系統中空閑塊的信息，例如，可以用位圖或者指針列表的形式給出。

BitMap位圖或者Bit vector位向量
位圖或位向量是一系列位或位的集合，其中每個位對應一個磁盤塊，該位可以采用兩個值：0和1, 0表示已分配該塊，而1表示一個空閑塊。

下圖中的磁盤上給定的磁盤塊實例(分配了綠色塊)可以用16位的位圖表示為：0000111000000110。

使用鏈表進行管理
在這種方法中，空閑磁盤塊鏈接在一起，即一個空閑塊包含指向下一個空閑塊的指針。第一個磁盤塊的塊號存儲在磁盤上的單獨位置，也緩存在內存中

碎片

這里不得不提一個叫做碎片(fragment)的概念，也稱為片段。一般零散的單個數據通常稱為片段。
磁盤塊可以進一步分為固定大小的分配單元，片段只是在驅動器上彼此不相鄰的文件片段。

如果你不理解這個概念就給你舉個例子。

比如你用Windows電腦創建了一個文件，你會發現這個文件可以存儲在任何地方，比如存在桌面上，存在磁盤中的文件夾中或者其他地方。
你可以打開文件，編輯文件，刪除文件等等。
你可能以為這些都在一個地方發生，但是實際上并不是，你的硬盤驅動器可能會將文件中的一部分存儲在一個區域內，另一部分存儲在另外一個區域，在你打開文件時，硬盤驅動器會迅速的將文件的所有部分匯總在一起，以便其他計算機系統可以使用它

inode

然后在后面是一個 inode(index node),也稱作索引節點。它是一個數組的結構，每個文件有一個 inode, inode非常重要，它說明了文件的方方面面。
每個索引節點都存儲對象數據的屬性和磁盤塊位置有一種簡單的方法可以找到它們Is -lai命令。

讓我們看一下根文件系統：

inode節點主要包括了以下信息
?模式/權限(保護)
?所有者ID
?組ID
?文件大小
?文件的硬鏈接數
?上次訪問時間
?最后修改時間
? inode上次修改時間
文件分為兩部分，索引節點和塊。一旦創建后，每種類型的塊數是固定的。你不能增加分區上inode的數量，也不能增加磁盤塊的數量。
緊跟在inode后面的是根目錄，它存放的是文件系統目錄樹的根部。最后，磁盤的其他部分存放了其他所有的目錄和文件。

2.文件的實現

最重要的問題是記錄各個文件分別用到了哪些磁盤塊。不同的系統采用了不同的方法。
背后的主要思想是有效利用文件空間和快速訪問文件，主要有三種分配方案
?連續分配
?鏈表分配
?索引分配

連續分配

最簡單的分配方案是把每個文件作為一連串連續數據塊存儲在磁盤上

因此，在具有1KB塊的磁盤上，將為50 KB文件分配50個連續塊。

上面展示了 40個連續的內存塊。從最左側的0塊開始。初始狀態下，還沒有裝載文件，因此磁盤是空的。
接著，從磁盤開始處（塊0 ）處開始寫入占用4塊長度的內存A。然后是一個占用6塊長度的內存B,會直接在A的末尾開始寫。
注意每個文件都會在新的文件塊開始寫，所以如果文件A只占用了 3又1/2個塊，那么最后一個塊的部分內存會被浪費。
在上面這幅圖中，總共展示了 7個文件，每個文件都會從上個文件的末尾塊開始寫新的文件塊。
連續的磁盤空間分配有兩個優點:
?第一，連續文件存儲實現起來比較簡單，只需要記住兩個數字就可以：一個是第一個塊的文件地址和文件的塊數量。給定第一個塊的編號，可以通過簡單的加法找到任何其他塊的編號。
?第二點是讀取性能比較強，可以通過一次操作從文件中讀取整個文件。只需要一次尋找第一個塊。
后面就不再需要尋道時間和旋轉延遲，所以數據會以全帶寬進入磁盤。

因此，連續的空間分配具有實現簡單、高性能的特點。

不幸的是，連續空間分配也有很明顯的不足。隨著時間的推移，磁盤會變得很零碎。

下圖解釋了這種現象

這里有兩個文件D和F被刪除了。當刪除一個文件時，此文件所占用的塊也隨之釋放，就會在磁盤空間中留下一些空閑塊。
磁盤并不會在這個位置擠壓掉空閑塊，因為這會復制空閑塊之后的所有文件，可能會有上百萬的塊，這個量級就太大了。
剛開始的時候，這個碎片不是問題，因為每個新文件都會在之前文件的結尾處進行寫入。
然而，磁盤最終會被填滿，因此要么壓縮磁盤、要么重新使用空閑塊的空間。壓縮磁盤的開銷太大，因此不可行；后者會維護一個空閑列表，這個是可行的。但是這種情況又存在一個問題，為空閑塊匹配合適大小的文件，需要知道該文件的最終大小。
想象一下這種設計的結果會是怎樣的。用戶啟動word進程創建文檔。應用程序首先會詢問最終創建的文檔會有多大。這個問題必須回答，否則應用程序就不會繼續執行。
如果空閑塊的大小要比文件的大小小，程序就會終止。因為所使用的磁盤空間已經滿了。那么現實生活中，有沒有使用連續分配內存的介質出現呢？
CD-ROM就廣泛的使用了連續分配方式。

CD-ROM (Compact Disc Read-Only Memory)即只讀光盤，也稱作只讀存儲器。
是一種在電腦上使用的光碟。
這種光碟只能寫入數據一次，信息將永久保存在光碟上，使用時通過光碟驅動器讀出信息。

然而DVD的情況會更加復雜一些。原則上，一個90分鐘的電影能夠被編碼成一個獨立的、大約4.5 GB的文件。
但是文件系統所使用的UDF(Universal Disk Format)格式，使用一個30位的數來代表文件長度，從而把文件大小限制在1 GB。
所以，DVD電影一般存儲在3、4個連續的1 GB空間內。這些構成單個電影中的文件塊稱為擴展區(extends)。
就像我們反復提到的，歷史總是驚人的相似，許多年前，連續分配由于其簡單和高性能被實際使用在磁盤文件系統中。后來由于用戶不希望在創建文件時指定文件的大小，于是放棄了這種想法。
但是隨著CD-ROM、DVD、藍光光盤等光學介質的出現，連續分配又流行起來。從而得出結論，技術永遠沒有過時性，現在看似很老的技術，在未來某個階段可能又會流行起來。

鏈表分配

第二種存儲文件的方式是為每個文件構造磁盤塊鏈表，每個文件都是磁盤塊的鏈接列表

就像下面所示:

每個塊的第一個字作為指向下一塊的指針，塊的其他部分存放數據。
如果上面這張圖你看的不是很清楚的話，可以看看整個的鏈表分配方案
與連續分配方案不同，這一方法可以充分利用每個磁盤塊。除了最后一個磁盤塊外，不會因為磁盤碎片而浪費存儲空間。同樣，在目錄項中，只要存儲了第一個文件塊，那么其他文件塊也能夠被找到。
另一方面，在鏈表的分配方案中，盡管順序讀取非常方便，但是隨機訪問卻很困難（這也是數組和鏈表數據結構的一大區別）。
還有一個問題是，由于指針會占用一些字節，每個磁盤塊實際存儲數據的字節數并不再是2的整數次冪。雖然這個問題并不會很嚴重，但是這種方式降低了程序運行效率。
許多程序都是以長度為2的整數次幕來讀寫磁盤，由于每個塊的前幾個字節被指針所使用，所以要讀出一個完成的塊大小信息，就需要當前塊的信息和下一塊的信息拼湊而成，因此就引發了查找和拼接的開銷。

使用內存表進行鏈表分配

由于連續分配和鏈表分配都有其不可忽視的缺點。

所以提出了使用內存中的表來解決分配問題。取出每個磁盤塊的指針字，把它們放在內存的一個表中，就可以解決上述鏈表的兩個不足之處。

下面是一個例子：

上圖表示了鏈表形成的磁盤塊的內容。這兩個圖中都有兩個文件，文件A依次使用了磁盤塊地址4、 7、2、10、12,文件B使用了6、3、11和14。
也就是說，文件A從地址4處開始，順著鏈表走就能找到文件A的全部磁盤塊。同樣，從第6塊開始，順著鏈走到最后，也能夠找到文件B的全部磁盤塊。
你會發現，這兩個鏈表都以不屬于有效磁盤編號的特殊標記（-1）結束。內存中的這種表格稱為文件分配表（File Application Table,FAT）。
使用這種組織方式，整個塊都可以存放數據。進而，隨機訪問也容易很多。雖然仍要順著鏈在內存中查找給定的偏移量，但是整個鏈都存放在內存中，所以不需要任何磁盤引用。
與前面的方法相同，不管文件有多大，在目錄項中只需記錄一個整數（起始塊號），按照它就可以找到文件的全部塊。
這種方式存在缺點，那就是必須要把整個鏈表放在內存中。對于1TB的磁盤和1KB的大小的塊，那么這張表需要有10億項。
每一項對應于這10億個磁盤塊中的一塊。每項至少3個字節，為了提高查找速度，有時需要4個字節。根據系統對空間或時間的優化方案，這張表要占用3GB或2.4GB的內存。
FAT的管理方式不能較好地擴展并應用于大型磁盤中。而這正是最初MS-DOS文件比較實用，并仍被各個Windows版本所安全支持。

inode

最后一個記錄各個文件分別包含哪些磁盤塊的方法是給每個文件賦予一個稱為inode（索引節點）的數據結構，每個文件都與一個iode進行關聯，inode由整數進行標識。

下面是一個簡單例子的描述：

相對于在內存中使用表的方式而言，這種機制具有很大的優勢。即只有在文件打開時，其inode才會在內存中。
如果每個inode需要n個字節，最多k個文件同時打開，那么inode占有總共打開的文件是 kn字節。僅需預留這么多空間。
這個數組要比我們上面描述的FAT（文件分配表）占用的空間小的多。原因是用于保存所有磁盤塊的鏈接列表的表的大小與磁盤本身成正比。
如果磁盤有n個塊，那么這個表也需要n項。隨著磁盤空間的變大，那么該表也隨之線性增長。
相反，inode需要節點中的數組，其大小和可能需要打開的最大文件個數成正比。它與磁盤是100GB. 4000GB還是10000GB無關。
inode的一個問題是如果每個節點都會有固定大小的磁盤地址，那么文件增長到所能允許的最大容量外會發生什么？
一個解決方案是最后一個磁盤地址不指向數據塊，而是指向一個包含額外磁盤塊地址的地址，如上圖所示。
一個更高級的解決方案是：有兩個或者更多包含磁盤地址的塊，或者指向其他存放地址的磁盤塊的磁盤塊。
Windows的NTFS文件系統采用了相似的方法，所不同的僅僅是大的inode也可以表示小的文件。

NTFS的全稱是New Technology File System ,是微軟公司開發的專用系統文件，NTFS取
代FAT（文件分配表）和HPFS（高性能文件系統），并在此基礎上進一步改進。例如增強對元數據
的支持，使用更高級的數據結構以提升性能、可靠性和磁盤空間利用率等。

3.目錄的實現

文件只有打開后才能夠被讀取。在文件打開后，操作系統會使用用戶提供的路徑名來定位磁盤中的目錄。
目錄項提供了查找文件磁盤塊所需要的信息。根據系統的不同，提供的信息也不同，可能提供的信息是整個文件的磁盤地址，或者是第一個塊的數量（兩個鏈表方案）或inode的數量。
不過不管用那種情況，目錄系統的主要功能就是將文件的ASCII碼的名稱映射到定位數據所需的信息上。
與此關系密切的問題是屬性應該存放在哪里。每個文件系統包含不同的文件屬性，例如文件的所有者和創建時間，需要存儲的位置。
一種顯而易見的方法是直接把文件屬性存放在目錄中。有一些系統恰好是這么做的，如下：
在這種簡單的設計中，目錄有一個固定大小的目錄項列表，每個文件對應一項，其中包含一個固定長度的文件名，文件屬性的結構體以及用以說明磁盤塊位置的一個或多個磁盤地址。
對于采用inode的系統，會把inode存儲在屬性中而不是目錄項中。在這種情況下，目錄項會更短：僅僅只有文件名稱和inode數量。

這種方式如下所示：

到目前為止，我們已經假設文件具有較短的、固定長度的名字。在MS-DOS中，具有1 - 8個字符的基本名稱和1 一 3個字符的可拓展名稱。
在UNIX版本7中，文件有1 - 14個字符，包括任何拓展。然而，幾乎所有的現代操作系統都支持可變長度的擴展名。這是如何實現的呢？
最簡單的方式是給予文件名一個長度限制，比如255個字符，然后使用上圖中的設計，并為每個文件名保留255個字符空間。
這種處理很簡單，但是浪費了大量的目錄空間，因為只有很少的文件會有那么長的文件名稱。所以，需要一種其他的結構來處理。
一種可選擇的方式是放棄所有目錄頊大小相同的想法。在這種方法中，每個目錄項都包含一個固定部分，這個固定部分通常以目錄項的長度開始，后面是固定格式的數據，通常包括所有者、創建時間、保護信息和其他屬性。這個固定長度的頭的后面是一個任意長度的實際文件名

如下圖所示：

處理機中的一串字符存放的順序有正序(big-endian)和逆序(little-endian)之分。正序存放的就是高字節在前低字節在后，而逆序存放的就是低字節在前高字節在后。
這個例子中，有三個文件，分別是project-budget、personnel和foo ，每個文件名以一個特殊字符(通常是0)結束，用矩形中的叉進行表示。
為了使每個目錄項從字的邊界開始，每個文件名被填充成整數個字

如下圖所示：

這個方法的缺點是當文件被移除后，就會留下一塊固定長度的空間，而新添加進來的文件大小不一定和空閑空間大小一致。
這個問題與我們上面探討的連續磁盤文件的問題是一樣的，由于整個目錄在內存中，所以只有對目錄進行緊湊拼接操作才可節省空間。
另一個問題是，一個目錄項可能會分布在多個頁上，在讀取文件名時可能發生缺頁中斷。
處理可變長度文件名字的另外一種方法是，使目錄項自身具有固定長度，而將文件名放在目錄末尾的堆棧中。
如上圖所示的這種方式。這種方法的優點是當目錄項被移除后，下一個文件將能夠正常匹配移除文件的空間。當然，必須要對堆進行管理，因為在處理文件名的時候也會發生缺貞異常。
到目前為止的所有設計中，在需要查找文件名時，所有的方案都是線性的從頭到尾對目錄進行搜索。對于特別長的目錄，線性搜索的效率很低。
提高文件檢索效率的一種方式是在每個目錄上使用哈希表 (hash table),也叫做散列表。
我們假設表的大小為n,在輸入文件名時，文件名被散列在。和n - 1之間，例如，它被n除，并取余數。或者對構成文件名字的字求和或類似某種方法。
無論采用哪種方式，在添加一個文件時都要對與散列值相對應的散列表進行檢查。
如果沒有使用過，就會將一個指向目錄項的指針指向這里。文件目錄項緊跟著哈希表后面。
如果已經使用過，就會構造一個鏈表，鏈表的表頭指針存放在表項中，并通過哈希值將所有的表項相連。
查找文件的過程和添加類似，首先對文件名進行哈希處理，在哈希表中查找是否有這個哈希值，如果有的話，就檢查這條鏈上所有的哈希項，查看文件名是否存在。如果哈希不在鏈上，那么文件就不在目錄中。
使用哈希表的優勢是查找非常迅速，缺點是管理起來非常復雜。只有在系統中會有成千上萬個目錄項存在時，才會考慮使用散列表作為解決方案。
另外一種在大量目錄中加快查找指令目錄的方法是使用緩存，緩存查找的結果。在開始查找之前，會首先檢查文件名是否在緩存中。如果在緩存中，那么文件就能立刻定位。當然，只有在較少的文件下進行多次查找，緩存才會發揮最大功效。

總結

以上是生活随笔為你收集整理的OS- -文件系统(二)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。