OS- -文件系統(三)

文章目錄

• OS- -文件系統(三)
• • 一、文件系統的實現
  • • 1.共享文件
    • 2.日志結構文件系統
    • 3.日志文件系統
    • 4.虛擬文件系統
  • 二、文件系統的管理和優化
  • • 1.磁盤空間管理
    • • 塊大小
      • 記錄空閑塊

一、文件系統的實現

1.共享文件

• 當多個用戶在同一個項目中工作時，他們通常需要共享文件。如果這個共享文件同時出現在多個用戶目 錄下，那么他們協同工作起來就很方便。

下面的這張圖我們在上面提到過，但是有一個更改的地方，就 是C的一個文件也出現在了 B的目錄下。

• 如果按照如上圖的這種組織方式而言，那么B的目錄與該共享文件的聯系稱為 鏈接(link)。那么文 件系統現在就是一個有向無環圖(Directed Acyclic Graph,簡稱DAG),而不是一棵樹了

• 在圖論中，如果一個有向圖從任意頂點出發無法經過若干條邊回到該點，則這個圖是一個有向無 環圖

• 將文件系統組織成為有向無環圖會使得維護復雜化，但也是必須要付出的代價。 共享文件很方便，但這也會帶來一些問題。
• 如果目錄中包含磁盤地址，則當鏈接文件時，必須把C目 錄中的磁盤地址復制到B目錄中。
• 如果B或者C隨后又向文件中添加內容，則僅在執行追加的用戶的 目錄中顯示新寫入的數據塊。這種變更將會對其他用戶不可見，從而破壞了共享的目的。
  
• 有兩種方案可以解決這種問題：
• ?第一種解決方案，磁盤塊不列入目錄中，而是會把磁盤塊放在與文件本身相關聯的小型數據結構中。目錄將指向這個小型數據結構。這是UNIX中使用的方式(小型數據結構就是inode)
• ?在第二種解決方案中，通過讓系統建立一個類型為LINK的新文件，并把該文件放在B的目錄 下，使得B與C建立鏈接。新的文件中只包含了它所鏈接的文件的路徑名。
• 當B想要讀取文件 時，操作系統會樓查B的目錄下存在一個類型為LINK的文件，進而找到該鏈接的文件和路徑名, 然后再去讀文件，這種方式稱為 符號鏈接(symbolic linking)
  
• 上面的每一種方法都有各自的缺點，在第一種方式中，B鏈接到共享文件時，inode記錄文件的所有者 為C。

建立一個鏈接并不改變所有關系，如下圖所示：

• 第一開始的情況如圖a所示，此時C的目錄的所有者是C ,當目錄B鏈接到共享文件時，并不會改變 C的所有者關系，只是把計數+ 1,所以此時系統知道目前有多少個目錄指向這個文件。
• 然后C嘗試 刪除這個文件，這個時候有個問題，如果C把文件移除并清除了 inode的話，那么B會有一個目錄項 指向無效的節點
• 如果inode以后分配給另一個文件，則B的鏈接指向一個錯誤的文件。系統通過 inode可知文件仍在被引用，但是沒有辦法找到該文件的全部目錄項以刪除它們。
• 指向目錄的指針不能 存儲在inode中，原因是有可能有無數個這樣的目錄。
• 所以我們能做的就是刪除C的目錄項，但是將inode保留下來，并將計數設置為1,如上圖c所示。 c表示的是只有B有指向該文件的目錄項，而該文件的前者是C。如果系統進行記賬操作的話，那么 C將繼續為該文件付賬直到B決定刪除它，如果是這樣的話，只有到計數變為0的時刻，才會刪除該 文件。
• 對于符號鏈接，以上問題不會發生，只有真正的文件所有者才有一個指向inode的指針。鏈接到該文 件上的用戶只有路徑名，沒有指向inode的指針。
• 當文件所有者刪除文件時，該文件被銷毀。以后若試 圖通過符號鏈接訪問該文件將會失敗，因為系統不能找到該文件。刪除符號鏈接不會影響該文件。
• 符號鏈接的問題是需要額外的開銷。必須讀取包含路徑的文件，然后要一個部分接一個部分地掃描路 徑，直到找到inode。這些操作也許需要很多次額外的磁盤訪問。
• 此外，每個符號鏈接都需要額外的 inode,以及額外的一個磁盤塊用于存儲路徑，雖然如果路徑名很短，作為一種優化，系統可以將它存 儲在inode中。
• 符號鏈接有一個優勢，即只要簡單地提供一個機器的網絡地址以及文件在該機器上駐留 的路徑，就可以連接全球任何地方機器上的文件。
• 還有另一個由鏈接帶來的問題，在符號鏈接和其他方式中都存在。如果允許鏈接，文件有兩個或多個路 徑。查找一指定目錄及其子目錄下的全部文件的程序將多次定位到被鏈接的文件。
• 例如，一個將某一目 錄及其子目錄下的文件轉存到磁帶上的程序有可能多次復制一個被鏈接的文件。
• 進而，如果接著把磁帶 讀入另一臺機器，除非轉出程序具有智能，否則被鏈接的文件將被兩次復制到磁盤上，而不是只是被鏈 接起來。

2.日志結構文件系統

• 技術的改變會給當前的文件系統帶來壓力。這種情況下，CPU會變得越來越快，磁盤會變得越來越大 并且越來越便宜（但不會越來越快）。
• 內存容量也是以指數級增長。但是磁盤的尋道時間（除了固態 盤，因為固態盤沒有尋道時間）并沒有獲得提高。
• 這些因素結合起來意味著許多系統文件中出現性能瓶頸。為此，Berkeley設計了一種全新的文件系 統，試圖緩解這個問題，這個文件系統就是 日志結構文件系統（Log-structured File System, LFS）
• 日志結構文件系統由Rosenblum和Ousterhout于90年代初引入，旨在解決以下問題。
• ?不斷增長的系統內存
• ?順序I/O性能勝過隨機I/O性能
• ?現有低效率的文件系統
• ?文件系統不支持RAID （虛擬化）
• 另一方面，當時的文件系統不論是UNIX還是FFS,都有大量的隨機讀寫（在FFS中創建一個新文件至少需要5次隨機寫），因此成為整個系統的性能瓶頸。
• 同時因為Page cache的存在，作者認為隨 機讀不是主要問題：隨著越來越大的內存，大部分的讀操作都能被cache,因此LFS主要要解決的是 減少對硬盤的隨機寫操作。
• 在這種設計中，inode甚至具有與UNIX中相同的結構，但是現在它們分散在整個日志中，而不是位于 磁盤上的固定位置。
• 所以，inode很定位。為了能夠找到inode ,維護了一個由inode索引的inode map(inode映射)。表項i指向磁盤中的第i個inode o這個映射保存在磁盤中，但是也保存在緩存 中，因此，使用最頻繁的部分大部分時間都在內存中。

• 結構文件系統主要使用四種數據結構：Inode、Inode Map、Segment. Segment Usage Tableo

• 到目前為止，所有寫入最初都緩存在內存中，并且追加在日志末尾，所有緩存的寫入都定期在單個段中寫入磁盤。所以，現在打開文件也就意味著用映射定位文件的索引節點。
• 一旦inode被定位后，磁盤 塊的地址就能夠被找到。所有這些塊本身都將位于日志中某處的分段中。
• 真實情況下的磁盤容量是有限的，所以最終日志會占滿整個磁盤空間，這種情況下就會出現沒有新的磁 盤塊被寫入到日志中。
• 幸運的是，許多現有段可能具有不再需要的塊。例如，如果一個文件被覆蓋了， 那么它的inode將被指向新的塊，但是舊的磁盤塊仍在先前寫入的段中占據著空間。
• 為了處理這個問題，LFS有一個清理(clean)線程，它會循環掃描日志并對日志進行壓縮。
• 首先，通 過查看日志中第一部分的信息來查看其中存在哪些索引節點和文件。它會檢查當前inode的映射來查看 inode否在在當前塊中，是否仍在被使用。
• 如果不是，該信息將被丟棄。如果仍然在使用，那么inode 和塊就會進入內存等待寫回到下一個段中。
• 然后原來的段被標記為空閑，以便日志可以用來存放新的數 據。
• 用這種方法，清理線程遍歷日志，從后面移走舊的段，然后將有效的數據放入內存等待寫到下一個 段中。
• 由此一來整個磁盤會形成一個大的環形緩沖區，寫線程將新的段寫在前面，而清理線程則清理 后面的段。
  

3.日志文件系統

• 雖然日志結構系統的設計很優雅，但是由于它們和現有的文件系統不相匹配，因此還沒有廣泛使用。
• 不 過，從日志文件結構系統衍生出來一種新的日志系統，叫做日志文件系統，它會記錄系統下一步將要 做什么的日志。
• 微軟的NTFS文件系統、Linux的ext3就使用了此日志。OS X將日志系統作為 可供選項。
• 為了看清它是如何工作的，我們下面討論一個例子，比如移除文件，這個操作在UNIX中 需要三個步驟完成：
• ?在目錄中刪除文件
• ?釋放inode到空閑inode池
• ?將所有磁盤塊歸還給空閑磁盤池。
• 在Windows中，也存在類似的步驟。不存在系統崩潰時，這些步驟的執行順序不會帶來問題。但是一 旦系統崩潰，就會帶來問題。

• 假如在第一步完成后系統崩潰。
• inode和文件塊將不會被任何文件獲得，也不會再分配；它們只存在于廢物池中的某個地方，并因此減少了可利用的資源。
• 如果崩潰發生在第二步后，那么只有磁盤塊會丟失。
• 日志文件系統保留磁盤寫入期間對文件系統所做的更改的日志或日志，該日志可用于快速重建可能由于系統崩潰或斷電等事件而發生的損壞。
• 一般文件系統崩潰后必須運行fsck (文件系統一致性檢查)實用程序。

• 為了讓日志能夠正確工作，被寫入的日志操作必須是 慕等的(idempotent),它意味著只要有必要，它們就可以重復執行很多次，并不會帶來破壞。
• 像操作更新位表并標記inode k或者塊n是空閑的可 以重復執行任意次。同樣地，查找一個目錄并且刪除所有叫foobar的項也是幕等的。
• 相反，把從 inode k新釋放的塊加入空閑表的末端不是幕等的，因為它們可能已經被釋放并存放在那里了。
  
• 為了增加可靠性，一個文件系統可以引入數據庫中 原子事務(atomic transaction)的概念。
• 使用 這個概念，一組動作可以被界定在開始事務和結束事務操作之間。這樣，文件系統就會知道它必須完成 所有的動作，要么就一個不做。

4.虛擬文件系統

即使在同一臺計算機上或者在同一個操作系統下，都會使用很多不同的文件系統。

• Windows中的主要 文件系統是NTFS文件系統，但不是說Windows只有NTFS操作系統，它還有一些其他的例如舊的 FAT -32或FAT -16驅動器或分區，其中包含仍需要的數據，閃存驅動器，舊的CD-ROM或 DVD (每個都有自己的獨特文件系統)。
• Windows通過指定不同的盤符來處理這些不同的文件系統， 比如C: , D:等。盤符可以顯示存在也可以隱式存在，如果你想找指定位置的文件，那么盤符是顯 示存在；如果當一個進程打開一個文件時，此時盤符是隱式存在，所以Windows知道向哪個文件系統 傳遞請求。
• 相比之下，UNIX采用了一種不同的方式，即UNIX把多種文件系統整合到一個統一的結構中。
• 一個 Linux系統可以使用ext2作為根文件系統，ext3分區裝載在/usr下，另一塊采用Reiser FS文件系統的硬盤裝載到/home下，以及一個ISO 9660的CD - ROM臨時裝載到/mnt下。
• 從 用戶的觀點來看，只有一個文件系統層級，但是事實上它們是由多個文件系統組合而成，對于用戶和進 程是不可見的。
• UNIX操作系統使用一種虛擬文件系統(Virtual File System, VFS)來嘗試將多種文件系統構成一 個有序的結構。
• 關鍵的思想是抽象出所有文件系統都共有的部分，并將這部分代碼放在一層，這一層再 調用具體文件系統來管理數據。

下面是一個VFS的系統結構：

• 還是那句經典的話，在計算機世界中，任何解決不了的問題都可以加個代理來解決。所有和文件相關 的系統調用在最初的處理上都指向虛擬文件系統。
• 這些來自用戶進程的調用，都是標準的POSIX系統 調用，比如open、read、write和seek等。VFS對用戶進程有一個 上層 接口，這個接口就是著名 的 POSIX 接口。
• VFS也有一個對于實際文件的 下層 接口，就是上圖中標記為VFS的接口。這個接口包含許多功能調 用，這樣VFS可以使每一個文件系統完成任務。
• 因此，要創建一個可以與VFS-起使用的新文件系 統，新文件系統的設計者必須確保它提供了 VFS要求的功能。
• 一個明顯的例子是從磁盤讀取特定的 塊，然后將其放入文件系統的緩沖區高速緩存中，然后返回指向該塊的指針的函數。因此，VFS具有兩 個不同的接口：上一個到用戶進程，下一個到具體文件系統。
• 當系統啟動時，根文件系統在VFS中注冊。另外，當裝載其他文件時，不管在啟動時還是在操作過程 中，它們也必須在VFS中注冊。
• 當一個文件系統注冊時，根文件系統注冊到VFS。另外，在引導時或 操作期間掛載其他文件系統時，它們也必須向VFS注冊。
• 當文件系統注冊時，其基本作用是提供VFS 所需功能的地址列表、調用向量表、或者VFS對象。因此一旦文件系統注冊到VFS,它就知道從哪里開始讀取數據塊。裝載文件系統后就可以使用它了。

比如，如果一個文件系統裝載到/usr并且一個進程調用它:

open("/usr/include/unistd.h",O_RDONLY)

• 當解析路徑時，VFS看到新的文件系統被掛載到/usr ,并且通過搜索已經裝載文件系統的超級塊來 確定它的超塊。
• 然后它找到它所轉載的文件的根目錄，在那里查找路徑include/unistd.h。然后 VFS創建一個vnode并調用實際文件系統，以返回所有的在文件inode中的信息。
• 這個信息和其他信 息一起復制到vnode (內存中)。而這些其他信息中最重要的是指向包含調用vnode操作的函數表的 指針,比如reads write和close等。
• 當vnode被創建后，為了進程調用，VFS在文件描述符表中創建一個表項，并將它指向新的vnode, 最后，VFS向調用者返回文件描述符，所以調用者可以用它去read、write或者close文件。
• 當進程用文件描述符進行一個讀操作時，VFS通過進程表和文件描述符確定vnode的位置，并跟隨指 針指向函數表，這樣就調用了處理read函數，運行在實際系統中的代碼并得到所請求的塊。
• VFS不知 道請求時來源于本地硬盤、還是來源于網絡中的遠程文件系統、CD-ROM . USB或者其他介質，所有 相關的數據結構歐如下圖所示：
  
• 從調用者進程號和文件描述符開始，進而是vnode,讀函數指針，然后是對實際文件系統的訪問函數定 位。

二、文件系統的管理和優化

能夠使文件系統工作是一回事，能夠使文件系統高效、穩定的工作是另一回事，下面我們就來探討一下 文件系統的管理和優化。

1.磁盤空間管理

文件通常存在磁盤中，所以如何管理磁盤空間是一個操作系統的設計者需要考慮的問題。

• 在文件上進行 存儲有兩種策略：分配n個字節的連續磁盤空間；或者把文件拆分成多個并不一定連續的塊。在存儲管理系統中，主要有分段管理和分頁管理兩種方式。
• 正如我們所看到的，按連續字節序列存儲文件有一個明顯的問題，當文件擴大時，有可能需要在磁盤 上移動文件。內存中分段也有同樣的問題。
• 不同的是，相對于把文件從磁盤的一個位置移動到另一個位 置，內存中段的移動操作要快很多。因此，幾乎所有的文件系統都把文件分割成固定大小的塊來存儲。

塊大小

• 一旦把文件分為固定大小的塊來存儲，就會出現問題，塊的大小是多少？
• 按照磁盤組織方式，扇區、磁 道和柱面顯然都可以作為分配單位。在分頁系統中，分頁大小也是主要因素。
• 擁有大的塊尺寸意味著每個文件，甚至1字節文件，都要占用一個柱面空間，也就是說小文件浪費了大 量的磁盤空間。
• 另一方面，小塊意味著大部分文件將會跨越多個塊，因此需要多次搜索和旋轉延退才能 讀取它們，從而降低了性能。
• 因此，如果分配的塊太大會浪費空間；分配的塊太小會浪費時間

記錄空閑塊

• 一旦指定了塊大小，下一個問題就是怎樣跟蹤空閑塊。

• 有兩種方法被廣泛采用，如下圖所示：
  

• 第一種方法是采用磁盤塊鏈表，鏈表的每個塊中包含極可能多的空閑磁盤塊號。

• 對于1 KB的塊和32 位的磁盤塊號，空閑表中每個塊包含有255個空閑的塊號。

• 考慮1TB的硬盤，擁有大概十億個磁盤 塊。

• 為了存儲全部地址塊號，如果每塊可以保存255個塊號，貝蠕要將近400萬個塊。通常，空閑塊 用于保存空閑列表，因此存儲基本上是空閑的。

• 另一種空閑空間管理的技術是位圖(bitmap) , n個塊的磁盤需要n位位圖。

• 在位圖中，空閑塊用1 表示，已分配的塊用0表示。

• 對于1 TB硬盤的例子，需要10億位表示，即需要大約130 000個1 KB塊存儲。很明顯，和32位鏈表模型相比，位圖需要的空間更少，因為每個塊使用1位。只有當磁 盤快滿的時候，鏈表需要的塊才會比位圖少。

• 如果空閑塊是長期連續的話，那么空閑列表可以改成記錄連續分塊而不是單個的塊。

• 每個塊都會使用8 位、16位、32位的計數來與每個塊相聯，來記錄連續空閑塊的數量。

• 最好的情況是一個空閑塊可以用 兩個數字來表示：第一個空閑塊的地址和空閑塊的計數。

• 另一方面，如果磁盤嚴重碎片化，那么跟蹤連 續分塊要比跟蹤單個分塊運行效率低，因為不僅要存儲地址，還要存儲數量。

• 這種情況說明了一個操作系統設計者經常遇到的一個問題。有許多數據結構和算法可以用來解決 問題，但是選擇一個最好的方案需要數據的支持，而這些數據是設計者無法預先擁有的。只有在 系統部署完畢真正使用使用后才會獲得。

• 現在，回到空閑鏈表的方法，只有一個指針塊保存在內存中。創建文件時，所需要的塊從指針塊中取 出。當它用完時，將從磁盤中讀取一個新的指針塊。

• 類似地，刪除文件時，文件的塊將被釋放并添加到 主存中的指針塊中。當塊被填滿時，寫回磁盤。

在某些特定的情況下，這個方法導致了不必要的磁盤IO,如下圖所示:

• 上面內存中的指針塊僅有兩個空閑塊，如果釋放了一個含有三個磁盤塊的文件，那么該指針塊就會溢 出，必須將其寫入磁盤，那么就會產生如下圖的這種情況。
  
• 如果現在寫入含有三個塊的文件，已滿的指針不得不再次讀入，這將會回到上圖a中的情況。
• 如果有三 個塊的文件只是作為臨時文件被寫入，在釋放它時，需要進行另一次磁盤寫操作以將完整的指針塊寫回 到磁盤。
• 簡而言之，當指針塊幾乎為空時，一系列短暫的臨時文件可能會導致大量磁盤I/O。
• 避免大部分磁盤I/O的另一種方法是拆分完整的指針塊。這樣，當釋放三個塊時，變化不再是從a - b,而是從a - c,如下圖所示:
  
• 現在，系統可以處理一系列臨時文件，而不需要進行任何磁盤I/O。
• 如果內存中指針塊滿了，就寫入磁 盤，半滿的指針塊從磁盤中讀入。
• 這里的思想是：要保持磁盤上的大多數指針塊為滿的狀態(減少磁盤 的使用)，但是在內存中保留了一個半滿的指針塊。這樣，就可以既處理文件的創建又同時可以處理文 件的刪除操作，而不會為空閑表進行磁盤I/O。
• 對于位圖，會在內存中只保留一個塊，只有在該塊滿了或空了的情形下，才到磁盤上取另一個塊。
• 通過 在位圖的單一塊上進行所有的分配操作，磁盤塊會緊密的聚集在一起，從而減少了磁盤臂的移動。由于 位圖是一種固定大小的數據結構，所以如果內核是分頁的，就可以把位圖放在虛擬內存中，在需要時 將位圖的頁面調入。

總結

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

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