日志文件系統如何縮短系統重啟時間
如果發生系統崩潰，JFS 提供了快速文件系統重啟。通過使用數據庫日志技術，JFS 能在幾秒或幾分鐘之內把文件系統恢復到一致狀態，而非日志文件系統卻要花上幾小時甚至幾天才能完成。本白皮書對 JFS 體系結構作了概述，並且描述了可在 developerWorks 網站上找到的 JFS 技術的設計特性、潛在限制以及管理實用程序。
日志文件系統 (JFS) 提供了基於日志的字節級文件系統，該文件系統是為面向事務的高性能系統而開發的。它具有可伸縮性和健壯性，與非日志文件系統相比，它的優點是其快速重啟能力：JFS 能夠在幾秒或幾分鐘內就把文件系統恢復到一致狀態。
雖然 JFS 主要是為滿足服務器（從單處理器系統到高級多處理器和群集系統）的高吞吐量和可靠性需求而設計的，JFS 還可用於想得到高性能和可靠性的客戶機配置。
體系結構和設計
JFS 體系結構可從磁盤布局特性的角度進行說明。
邏輯卷
所有文件系統討論的基礎是某種類型的邏輯卷。這可以是一個物理磁盤，或物理磁盤空間的某個子集，例如：一個 FDISK 分區。邏輯卷也稱為磁盤分區。
聚集和文件集
文件系統創建實用程序 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 的字節塊，正如稀疏文件的情況一樣。
JFS 內部（潛在）限制
JFS 是完全 64 位的文件系統。所有 JFS 文件系統結構化字段都是 64 位大小。這允許 JFS 同時支持大文件和大分區。
文件系統大小
JFS 支持的最小文件系統是 16M 字節。最大文件系統的大小是文件系統塊尺寸和文件系統元數據結構支持的最大塊數兩者的乘積。JFS 將支持最大文件長度是 512 萬億字節（TB）（塊尺寸是 512 字節）到 4 千萬億字節（PB）（塊尺寸是 4K 字節）
文件長度
最大文件長度是主機支持的虛擬文件系統最大文件長度。例如：如果主機只支持 32 位，則這就限制了文件長度。
可移動媒體
JFS 不支持把軟盤作為基本文件系統設備。
標准管理實用程序
JFS 提供創建和維護文件系統的標准管理實用程序。
創建文件系統
這個實用程序提供 mkfs 命令的 JFS 特定部分，用來在指定的驅動器上初始化 JFS 文件系統。該實用程序在較低級別上操作，並假設文件系統所存在的任何卷的創建/初始化由更高級別的另一個實用程序處理。
檢查/修復文件系統
這個實用程序提供 fsck 命令的 JFS 特定部分。該命令檢查文件系統的一致性，修復發現的問題。它也重放日志，把提交的改動應用到文件系統元數據，如果由於日志重放而聲明文件系統是干淨的，就不會再采取進一步操作。如果文件系統不認為是干淨的，這意味著由於某種原因沒有完整和正確地重放日志，或者文件系統不能單靠重放日志來恢復到一致狀態，那麼，就對文件系統執行一遍完整檢查。
當執行全部完整性檢查時，檢查/修復實用程序首要目的是要達到可靠的文件系統狀態，以防止將來文件系統崩潰或故障，第二個目的就是面對崩潰時保存數據。這意味著為了達到文件系統的一致性，實用程序可能丟棄數據。具體而言，當實用程序在不做假設的情況下，無法獲得所需信息以將結構上不一致的文件或目錄恢復到一致狀態時，就會廢棄數據。當遇到不一致的文件或目錄時，就廢棄整個文件或目錄，而不再試圖保存任何部分。任何由刪除受損目錄所孤立起來的文件或子目錄，都放在文件系統根下的 lost+found 目錄中。
文件系統檢查/修復實用程序重點考慮的因素之一是所需虛存數量。通常，這些實用程序所需的虛存數量由文件系統的大小決定，這是由於所需虛存主要用於跟蹤文件系統中個別塊的分配狀態。隨著文件系統增大，塊的數量增多，用來跟蹤這些塊所需的虛存數量也隨之增加。
JFS 檢查/修復實用程序的設計區別在於其虛存需求由文件系統中文件和目錄的數量（而不是由塊的數量）所決定。對 JFS 檢查/修復實用程序而言，每個文件或目錄的虛存大約為每個文件或目錄 32 字節，或者對於包含百萬個文件和目錄的文件系統而言，不論其文件系統大小，虛存需求都是大約 32 兆字節。如同所有其它的文件系統，JFS 實用程序需要跟蹤塊分配狀態，但避免使用虛存方法，而是使用位於實際文件系統中的一小塊保留工作區來實現。
日志文件系統如何處理磁盤布局
本文描述磁盤日志文件系統(JFS)布局，以及使用磁盤布局結構來實現可擴展性、可靠性和性能的機制。還會了解用來操作這些結構的策略和算法，以及 JFS 是在哪裡使用遍布文件系統的 B+ 樹來提高文件系統操作性能。
JFS 體系結構可通過其磁盤布局特性的上下文進行說明。磁盤布局是 JFS 用來控制文件系統的格式。本文討論盤區的文件幾何構造、目錄格式、塊分配映射表格式、inode 和布局結構的其它特性。本文還提供了文件布局使用的 B+ 樹數據結構的細節和示例。選擇 B+ 樹是為了提高讀寫盤區的性能，這是 JFS 執行的最普通操作。
分區、聚集、分配組、文件集
分區
JFS 文件系統建立在分區上，分區是由 FDISK 導出到 JFS 的抽象。
分區有：
固定分區塊尺寸，其合法值為 512、1024、2048 或 4096 字節。分區塊尺寸定義了分區上支持的最小 I/O 單元。這對應於組成分區的物理設備的基本磁盤扇區大小，最普遍的尺寸是 512 字節。
大小為：PART_NBlocks，是分區磁盤塊數。
分區磁盤塊的抽象地址空間 [ 0.. PART_NBlocks - 1 ]。
聚集
為了支持 DCE DFS（分布式計算環境分布式文件系統），JFS 將磁盤空間分配池（稱為聚集）的概念, 與可安裝的文件系統子樹（稱為文件集）的概念分開。本文中聚集和文件集的術語與其 DFS 用法一致。每個分區剛好只有一個聚集；每個聚集可能有多個文件集。在第一個發行版中，JFS 僅支持每個聚集一個文件集；但是，所有元數據都已設計成適用於所有情況。
聚集有：
在此聚集的開始部分有 32K 保留區域。
固定的聚集塊尺寸，其合法值為 512、1024、2048 或 4096 字節，但不小於分區塊尺寸。聚集塊尺寸定義了聚集上支持的最小空間分配單元。不要把它與分區塊尺寸混淆起來，後者定義的是 I/O 的最小單元。
主聚集超級塊和輔助聚集超級塊。超級塊包含聚集方面的信息，例如：聚集的大小、分配組的大小、聚集塊的尺寸等等，輔助聚集超級塊是主聚集超級塊的直接副本。如果主聚集超級塊損壞，則使用輔助聚集超級塊。這些超級塊位於固定位置。這使得 JFS 不依賴任何其它信息，就能夠找到它們。超級塊結構在 jfs_superblock.h 的 strUCt jfs_superblock 中定義。
聚集 inode 表，包含描述聚集范圍的控制結構的 inode 。聚集 inode 表邏輯上包含一個 inode 數組。聚集無目錄結構；在聚集或文件集名字空間中，任何地方都沒有聚集 inode 。
輔助聚集 inode 表，包含從聚集 inode 表復制的 inode 。由於對任何文件系統信息的查找而言，聚集 inode 表中的 inode 都是至關重要的，所以它們每一個在輔助聚集 inode 表中都有備份。當然，不會復制 inode 的實際數據，而只是復制可用來查找數據和 inode 本身的尋址結構。
聚集 inode 映射表，描述聚集 inode 表。聚集 inode 分配映射表包含聚集 inode 上及其磁盤位置上的分配狀態信息。
輔助聚集 inode 映射表，描述輔助聚集 inode 表。由於必須復制聚集 inode 表本身，輔助聚集 inode 映射表實際上是與聚集 inode 分配映射表分開的映射結構。
塊分配映射表，描述在聚集內分配和釋放聚集磁盤塊的控制結構。塊分配映射表在聚集磁盤塊內進行一對一映射。
fsck 工作區，它為 fsck 提供用來跟蹤聚集塊分配的空間。因為 JFS 支持超大聚集，所以這一區域是必需的；當 fsck 運行時，可能沒有足夠的內存用來跟蹤內存中的這些信息。超級塊描述了這一區域。每個聚集塊需要一位。 fsck 工作區總是存在於聚集的末端。
內嵌日志為記錄聚集中的元數據更改提供了空間。超級塊描述了這一區域。內嵌日志總是緊跟 fsck 工作空間後。
初始情況下，在聚集創建時分配了第一個 inode 盤區。按需要動態分配和釋放其它 inode 盤區。每個聚集 inode 描述聚集本身的某些方面，如下：
保留聚集 inode 0。
聚集 inode 1，即自身 inode ，描述包括聚集 inode 映射表的聚集磁盤塊。這是一種循環表示法，因為聚集 inode 1 本身也在自己所描述的文件中。可通過強制規定至少第一個聚集 inode 盤區要在眾所周知的位置，即主聚集超級塊後面 4K 的位置，來處理以上顯而易見的循環表示法問題。因此，JFS 能輕而易舉地找到聚集 inode 1，從聚集 inode 1，通過跟隨 inode 1 中的 B+ 樹，能找到聚集 inode 表的余下 inode 。
要復制聚集 inode 表，JFS 還需要找到聚集 inode 1 的副本，以查找所復制表的其余部分。超級塊會包含一個盤區描述符，該描述符描述輔助聚集 inode 表的第一個 inode 盤區的位置。JFS 能夠從中找到輔助聚集 inode 1，以及輔助聚集 inode 表的余下部分。
聚集 inode 2 描述塊分配映射表。
聚集 inode 3 描述安裝時的內嵌日志。雖然分配了 inode ，但無數據存入磁盤。
聚集 inode 4 描述在聚集格式化期間發現的壞塊。在塊映射表中這些標記成已分配。該 inode 是數據為壞塊的普通文件。 保留聚集 inode 5 到 15 以備將來擴展。
從聚集 inode 16 開始，每個文件集有一個 inode ，即文件集分配映射表 inode 。這個 inode 描述了表示文件集的控制結構。當更多文件集添加到聚集中時，為了容納更多的文件集 inode ，聚集 inode 表本身可能必須增大。
分配組
分配組(AG)把聚集中的空間分成大塊，並且允許 JFS 資源分配策略使用眾所周知的方法，來實現更好的 JFS I/O 性能。首先，分配策略嘗試將相關數據的磁盤塊和磁盤 inode 集群起來，使磁盤實現好的局域性。文件通常是順序地讀寫，而目錄中的文件通常一起訪問。其次，為了容納局域性，分配策略嘗試在整個聚集中分配不相關數據。聚集內的分配組用從 0 開始的 AG（分配組）索引。即用 AG 標識。
必須選擇分配組大小，以使 AG 足夠大以不斷提供連續資源分配。為了將聚集擴充或縮小時所需進行的更新數最小化，分配組必須限制最大組數 128。此外，JFS 將對 8192 個聚集塊的分配組大小規定其最小值。分配組大小必須總是 1 個 dmap 頁（1、2、4、8、 ...dmap 頁）描述的塊數的 2 的冪次方。分配組大小在聚集超級塊中存儲。
大小不是分配組大小倍數的聚集將包含部分分配組；磁盤塊沒有完全覆蓋聚集的最後一個分配組。除了JFS 將標記在塊分配映射表中分配的卻不存在的磁盤塊之外，該部分分配組將被當作完整的分配組。
文件集
文件集是文件和目錄的集合，這些文件和目錄形成了可獨立安裝的子樹。文件集完全包含在一個聚集中。請注意，一個聚集中可能有多個文件集；在那種情況下，所有文件集共享由聚集控制結構定義的空閒聚集磁盤塊公共池。
文件集有：
文件集 inode 表，包含描述文件集范圍的控制結構的 inode 。文件集 inode 表邏輯上包含一個 inode 數組。
文件集 inode 分配映射表，描述文件集 inode 表。文件集 inode 分配映射表包含文件集 inode 上及其磁盤位置上的分配狀態信息。描述文件集分配映射表和其他文件集信息的超級 inode ，駐留前面所描述的聚集 inode 表中。由於復制了聚集 inode 表，因此這個 inode 存在第二個版本，它指向同樣的數據。超級 inode 本身是一個文件。當文件集一開始創建時，分配第一個 inode 盤區按需要動態分配和釋放其它 inode 盤區。
文件集中 inode 的分配如下所示：
保留文件集 inode 0。
文件集 inode 1 包含附加的文件集信息，它們無法放入聚集 inode 表中的文件集分配映射表 inode 。
文件集 inode 2 是文件集的根目錄 inode 。注意，JFS 保留了 inode 2 是文件系統的根這一公共 Unix 約定。
文件集 inode 3 是文件集的 ACL 文件。
從文件集 inode 4 開始，文件集 inode 用於一般文件集對象、用戶文件、目錄和符號鏈接。
盤區、inode 、B+ 樹
盤區是當作單元分配給 JFS 對象的連續聚集塊序列。盤區完全包含在一個聚集（並且因此也是在一個分區）中；但是，大盤區可能跨多個分配組。
每個 JFS 對象可用一個 inode 來表示。inode 包含預期的對象特定信息，例如：時間戳和文件類型。它們還包含記錄盤區分配的 B+ 樹。注意，所有 JFS 元數據結構（除超級塊之外）都以文件表示。通過重用這種數據的 inode 結構，數據格式（即磁盤布局) 自然是可擴展的。
盤區、B+ 樹、inode 在以下章節中詳細描述。
盤區
文件是按盤區順序分配的。盤區是當作一個單元分配的聚集塊的連續變長序列。盤區的尺寸范圍是 1 到 2(24)-1 個聚集塊。盤區可能跨越多個分配組(AG)。為了在插入新盤區、定位特定盤區等操作方面有更優性能，這些盤區是按 B+ 樹索引的。
定義一個盤區需要兩個值，即其長度和其地址。長度以聚集塊尺寸為單位計算。JFS 使用 24 位值來表示盤區的長度，因此盤區的范圍大小是 1 到 2(24)-1 個聚集塊。
對於 512 字節的聚集塊尺寸 (所允許的最小值)，最大盤區是512*(2(24)-1)字節，（比 8G 稍小)。對於 4096 字節的聚集塊尺寸（所允許的最大值），盤區的最大長度是 4096*(2(24)-1)字節，(比 64G 稍小)。這些限制僅適用於一個的盤區；對整體文件大小沒有限制作用。地址指的是盤區中第一個塊的地址。地址同樣以聚集塊為單位：它從聚集的開始處計算塊偏移量。
結合了用戶特定聚集塊尺寸的基於盤區的文件系統，允許 JFS 不需要單獨支持內部存儲碎片。可配置聚集使用小的聚集塊尺寸（例如，512 字節），以使大量小尺寸文件的聚集內部存儲碎片最小化。
通常，JFS 分配嘗試通過分配最小數量的盤區策略，而使每個盤區盡可能大。這就允許大的 I/O 傳送，結果使得性能提高。然而，對於特殊情況，不一定總有這種結果。例如，一個段的寫入時復制會造成連續盤區被分割成更小的連續盤區系列。另一種情況是盤區大小的限制。例如：由於 JFS 必須把整個盤區讀入內存，然後進行解壓縮，所以壓縮文件盤區大小是有限的。由於 JFS 的可用內存數量有限，因此它必須保證有足夠的空間用於解壓縮盤區。
提供了一個碎片整理實用程序，以減少動態分配／釋放可變長盤區時出現的外部存儲碎片。這種分配和釋放可能導致不相連的變長空閒盤區遍及整個聚集。碎片整理實用程序會把多個小的空閒盤區合並成一個較大的盤區。
inode
JFS 磁盤 inode 是 512 字節。一個 JFS 磁盤 inode 包含 4 組基本信息。第一組描述 JFS 對象的 POSIX 屬性。第二組描述 JFS 對象的其它屬性；這些屬性包括支持 VFS 必需的信息、操作系統環境特定的信息、以及 B+ 樹的頭部。第三組不是包含 B+ 樹根節點的盤區分配描述符就是包含內嵌數據。第四組包含擴展屬性、更多內嵌數據或附加的盤區分配描述符。在 jfs_dinode.h 的 struct dinode 中定義磁盤 inode 結構。
JFS 動態分配 inode 提供的好處如下：
inode 磁盤塊可放在任何磁盤地址，這使得 inode 號和位置分開。這種分離簡化了支持聚集和文件集重組，能夠使聚集縮小。可以移動 inode ，移動後號碼仍然相同。這允許 JFS 不必需要查找目錄結構就可以更新 inode 號。對於支持 DFS 文件集復制而言，這種分離也是必需的。當復制文件集時，僅復制 inode 。既然 JFS 能把新的 inode 放在磁盤的任意位置，新 inode 將有與從它們復制的 inode 相同的號碼。這允許 JFS 不需復制目錄結構並且更新 inode 號。
不再需要分配實際所需十倍的 inode 。這對於 JFS 中較大的 inode 尺寸（大於 512 字節）而言，尤為重要。
大文件的文件分配可能消耗多個分配組且仍是連續的，而靜態分配造成間隔（由於每個分配組中初始分配的 inode ）。
另一方面，動態 inode 分配造成大量問題，包括：
對於靜態分配，文件系統的幾何構造隱含描述了磁盤上 inode 的布局；對於動態分配，必需有單獨的映射結構。
對 JFS 完整性而言，這些映射結構是至關重要的。由於復制這些結構的系統開銷，JFS 決定接受丟失這些映射表的風險。但是，JFS 將復制 B+ 樹結構，該結構允許 JFS 查找映射表。
通過只分配磁盤上 inode 連續大塊的 inode 盤區，動態分配了 inode 。根據定義，一個 JFS inode 盤區包含 32 個 inode 。對於 512 字節的 inode 尺寸，因此磁盤上一個 inode 盤區的大小是 16KB。
當分配新的 inode 盤區時，並不初始化盤區。然而，要使 fsck 能夠檢查是否 inode 在使用中，JFS 需要 inode 的一些信息。一旦盤區中的 inode 標記成在使用中，就必須初始化它的文件集號、inode 號、inode 戳以及 inode 分配組塊地址。因此，鏈接字段就足以確定 inode 當前是否正在使用。
注意，動態 inode 分配意味著在 inode 號與 inode 的磁盤地址之間沒有直接關系。因此，JFS 必須有查找磁盤上 inode 的方法。inode 分配映射表提供了這一功能。
inode 生成號只是每當重用 inode 時值就增加的計數器。
存儲每個 inode 生成計數器這一靜態 inode 分配常用方法在動態 inode 分配中不起作用，因為當 inode 空閒時，其磁盤空間可能確實由不是 inode 的數據所重用，（換句話說，空間可能被收回，以存儲普通文件數據）。因此，在 JFS 中，只有一個 inode 生成計數器，它在每一個 inode 分配時增加其值，即在重用 inode 時，相應的計數器增加其值，而不是每個 inode 有一個計數器。
