jfs
jfs
JFS( JOURNAL FILE SYSTEM),一種位元組級日誌文件系統,借鑒了資料庫保護系統的技術,以日誌的形式記錄文件的變化。JFS通過記錄文件結構而不是數據本身的變化來保證數據的完整性。這種方式可以確保在任何時刻都能維護數據的可訪問性。
體系結構和設計
JFS 體系結構可從磁碟布局特性的角度進行說明。
。
聚集和文件集
文件系統創建實用程序 mkfs,創建了完全包含在分區內的聚集。聚集是包含一種特定格式的磁碟塊陣列,其格式包括超級塊和分配映射表。超級塊將分區標識成 JFS 聚集,而分配映射表描述聚集內每個數據塊的分配狀態。格式還包括描述它所必需的初始文件集和控制結構。文件集是可安裝的實體。
文件、目錄、inode 與定址結構
文件集包含文件和目錄。文件和目錄由 inode 持續表示;每個 inode 描述文件或目錄的屬性,並作為查找磁碟上文件或目錄數據的起始點。JFS 還使用 inode 來表示其它文件系統對象,如描述文件集中每個 inode 的分配狀態和磁碟位置的映射表。
目錄將用戶特定的名稱映射到為文件和目錄所分配的 inode 上,並且形成傳統的命名層次。文件包含用戶數據,用戶數據中沒有隱含任何限制或格式。也就是說,JFS 將用戶數據看成是未解釋的位元組流。根植於 inode 基於盤區的定址結構用來將文件數據映射到磁碟。聚集超級塊和磁碟分配映射表、文件描述符和 inode 映射表、inode、目錄以及定址結構一起表示了 JFS 控制結構或元數據。
日誌
在每個聚集中維護 JFS 日誌,並且用來記錄元數據的操作信息。日誌有一種同樣由文件系統創建實用程序設置的格式。聚集內多個安裝的文件集可以同時使用一個日誌。
JFS 從一開始就設計成完全集成了日誌記錄,而不是在現有文件系統上添加日誌記錄。JFS 的許多特性使之區別於其它文件系統
。
日誌處理
JFS 提供了改進的結構化一致性和可恢復性,以及比非日誌文件系統(例如:HPFS、ext2 和傳統 UNIX 文件系統)快得多的系統重啟時間。發生系統故障時非日誌文件系統容易崩潰,是由於一個邏輯寫文件操作通常佔用多個媒體 I/O 來完成,且在任何給定時間,可能沒有完全反映在媒體上。這些文件系統依靠重啟實用程序(也就是 fsck),fsck 檢查文件系統的所有元數據(例如:目錄和磁碟定址結構)以檢測和修復結構完整性問題。這是一個耗時並且容易出錯的過程,在最糟糕的情況下,它還可能丟失或放錯數據。
相反,JFS 使用原來為資料庫開發的技術,記錄了文件系統元數據上執行的操作(即原子事務)信息。如果發生系統故障,可通過重放日誌並對適當的事務應用日誌記錄,來使文件系統恢復到一致狀態。由於重放實用程序只需檢查文件系統最近活動所產生的運行記錄,而不是檢查所有文件系統的元數據,因此,與這種基於日誌的方法相關的文件系統恢復時間要快得多。
基於日誌恢復的其它幾個方面也值得注意。首先,JFS 只記錄元數據上的操作,因此,重放這些日誌只能恢復文件系統中結構關係和資源分配狀態的一致性。它沒有記錄文件數據,也沒有將這些數據恢復到一致狀態。因此,恢復后某些文件數據可能丟失或失效,對數據一致性有關鍵性需求的用戶應該使用同步 I/O。
面對媒體出錯,日誌記錄不是特別有效。特別地,在將日誌或元數據寫入磁碟的期間發生的 I/O 錯誤,意味著在系統崩潰后,要將文件系統恢復到一致狀態,需要耗時並且有可能強加的全面完整性檢查。這暗示著,壞塊重定位是任何駐留在 JFS 下的存儲管理器或設備的一個關鍵特性。
JFS 日誌記錄的語義如下:當涉及元數據更改的文件系統操作--例如,unlink()--返回成功執行的返回碼時,操作的結果已經提交到文件系統,即使系統崩潰了也可以發現。例如,一旦成功刪除了文件,即使系統崩潰然後重啟,它仍然是刪除的並且不會再重新出現。
日誌記錄風格將同步寫入日誌磁碟引入每個修改元數據的 inode 或 vfs 操作。(對資料庫專家而言,這是一種使用非剝奪緩衝區策略的僅重做的、物理殘留映象、提前寫的日誌記錄協議。)在性能方面,與依賴(多個)謹慎的同步元數據寫操作以獲得一致性的許多非日誌文件系統相比,這種方法較好。但是,與其它日誌文件系統相比,它在性能上處於劣勢。其它日誌文件系統,如 Veritas VxFS 和 Transarc Episode,使用不同的日誌風格並且緩慢地將日誌數據寫入磁碟。在執行多個并行操作的伺服器環境中,通過將多個同步寫操作組合成單一寫操作的組提交來減少這種性能損失。JFS 日誌記錄風格隨著時間推移而得到不斷改進,現在提供了非同步日誌記錄,非同步日誌記錄提高了文件系統的性能。
基於盤區的定址結構
JFS 使用基於盤區的定址結構,連同主動的塊分配策略,產生緊湊、高效、可伸縮的結構,以將文件中的邏輯偏移量映射成磁碟上的物理地址。盤區是象一個單元那樣分配給文件的相連塊序列,可用一個由 <邏輯偏移量,長度,物理地址> 組成的三元組來描述。定址結構是一棵 B+ 樹,該樹由盤區描述符(上面提到的三元組)填充,根在 inode 中,鍵為文件中的邏輯偏移量。
可變的塊尺寸
按文件系統分,JFS 支持 512、1024、2048 和 4096 位元組的塊尺寸,以允許用戶根據應用環境優化空間利用率。較小的塊尺寸減少了文件和目錄中內部存儲碎片的數量,空間利用率更高。但是,小塊可能會增加路徑長度,與使用大的塊尺寸相比,小塊的塊分配活動可能更頻繁發生。因為伺服器系統通常主要考慮的是性能,而不是空間利用率,所以預設塊尺寸為 4096 位元組。
動態磁碟 inode 分配
JFS 按需為磁碟 inode 動態地分配空間,同時釋放不再需要的空間。這一支持避開了在文件系統創建期間,為磁碟 inode 保留固定數量空間的傳統方法,因此用戶不再需要估計文件系統包含的文件和目錄最大數目。另外,這一支持使磁碟 inode 與固定磁碟位置分離。
目錄組織
JFS 提供兩種不同的目錄組織。第一種組織用於小目錄,並且在目錄的 inode 內存儲目錄內容。這就不再需要不同的目錄塊 I/O,同時也不再需要分配不同的存儲器。最多可有 8 個項可直接存儲在 inode 中,這些項不包括自己(.)和父(..)目錄項,這兩個項存儲在 inode 中不同的區域內。
第二種組織用於較大的目錄,用按名字鍵控的 B+ 樹表示每個目錄。與傳統無序的目錄組織比較,它提供更快的目錄查找、插入和刪除能力。
稀疏和密集文件
按文件系統分,JFS 既支持稀疏文件也支持密集文件。
稀疏文件允許把數據寫到一個文件的任意位置,而不要將以前未寫的中間文件塊實例化。所報告的文件大小是已經寫入的最高塊位處,但是,在文件中任何給定塊的實際分配,只有在該塊進行寫操作時才發生。例如,假設在一個指定為稀疏文件的文件系統中創建一個新文件。應用程序將數據塊寫到文件中第 100 塊。儘管磁碟空間只分配了 1 塊給它,JFS 將報告該文件的大小為 100 塊。如果應用程序下一步讀取文件的第 50 塊,JFS 將返回填充了 0 的一個位元組塊。假設應用程序然後將一塊數據寫到該文件的第 50 塊,JFS 仍然報告文件的大小為 100 塊,而現在已經為它分配了兩塊磁碟空間。稀疏文件適合需要大的邏輯空間但只使用這個空間的一個(少量)子集的應用程序。
對於密集文件,將分配相當於文件大小的磁碟資源。在上例中,第一個寫操作(將一塊數據寫到文件的第 100 塊)將導致把 100 個塊的磁碟空間分配給該文件。在任何已經隱式寫入的塊上進行讀操作,JFS 將返回填充了 0 的位元組塊,正如稀疏文件的情況一樣。