The Second Extended File System
Internal Layout
Ext2文件系統的內部布局
Dave Poirier
instinc@users.sf.net
翻譯：Vitamin C[抗壞血酸]
sing9806@sohu.com
sing9806@yahoo.com.cn
Copyright © 2001-2002 by Dave Poirier
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license can be acquired electronically from http://www.fsf.org/licenses/fdl.html or by writing to 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
（這是原文關於版權的說明，予原樣保留。）
內容目錄
關於本書
1. 磁碟組織
1.1. 超級塊
1.1.1. s_inodes_count
1.1.2. s_blocks_count
1.1.3. s_r_blocks_count
1.1.4. s_free_blocks_count
1.1.5. s_free_inodes_count
1.1.6. s_first_data_block
1.1.7. s_log_block_size
1.1.8. s_log_frag_size
1.1.9. s_blocks_per_group
1.1.10. s_frags_per_group
1.1.11. s_inodes_per_group
1.1.12. s_mtime
1.1.13. s_wtime
1.1.14. s_mnt_count
1.1.15. s_max_mnt_count
1.1.16. s_magic
1.1.17. s_state
1.1.18. s_errors
1.1.19. s_minor_rev_level
1.1.20. s_lastcheck
1.1.21. s_checkinterval
1.1.22. s_creator_os
1.1.23. s_rev_level
1.1.24. s_def_resuid
1.1.25. s_def_resgid
1.1.26. s_first_ino
1.1.27. s_inode_size
1.1.28. s_block_group_nr
1.1.29. s_feature_compat
1.1.30. s_feature_incompat
1.1.31. s_feature_ro_compat
1.1.32. s_uuid
1.1.33. s_volume_name
1.1.34. s_last_mounted
1.1.35. s_algo_bitmap
1.2. 塊組描述符
1.2.1. bg_block_bitmap
1.2.2. bg_inode_bitmap
1.2.3. bg_inode_table
1.2.4. bg_free_blocks_count
1.2.5. bg_free_inodes_count
1.2.6. bg_used_dirs_count
1.2.7. bg_pad
1.2.8. bg_reserved
1.3. 塊點陣圖
1.4. Inode 點陣圖
1.5. Inode 表
1.5.1. i_mode
1.5.2. i_uid
1.5.3. i_size
1.5.4. i_atime
1.5.5. i_ctime
1.5.6. i_mtime
1.5.7. i_dtime
1.5.8. i_gid
1.5.9. i_links_count
1.5.10. i_blocks
1.5.11. i_flags
1.5.12. i_osd1
1.5.13. i_block
1.5.14. i_generation
1.5.15. i_file_acl
1.5.16. i_dir_acl
1.5.17. i_faddr
1.5.18. i_osd2
1.6. 數據塊
2. 目錄結構
2.1. 目錄文件格式
2.1.1. inode
2.1.2. rec_len
2.1.3. name_len
2.1.4. file_type
2.1.5.name
2.2. 目錄例子
2.3. 索引目錄格式
2.3.1. 索引結構
2.3.2. 查找演算法
2.3.3. 插入演算法
2.3.4. 拆分
2.3.5. Key 衝突
2.3.6. Hash 功能
2.3.7. 性能
3. Inode, 文件的標識符
3.1. Inode 號
3.2. 定位Inode 結構
3.3. 定位Inode 表
4. 文件屬性
4.1. 標準屬性
4.1.1. SUID, SGID 和 -rwxrwxrwx
4.1.2. 文件大小
4.1.3. 屬主與屬組
4.2. 擴展屬性
4.2.1. 屬性塊頭部
4.2.2. 屬性入口頭部
4.3. 行為控制標記
4.3.1. EXT2_SECRM_FL ? 安全刪除
4.3.2. EXT2_UNRM_FL ? 用於反刪除的記錄
4.3.3. EXT2_COMPR_FL ? 壓縮的文件
4.3.4. EXT2_SYNC_FL ? 同步更新
4.3.5. EXT2_IMMUTABLE_FL ? 不可變文件
4.3.6. EXT2_APPEND_FL ? 只添加
4.3.7. EXT2_NODUMP_FL ? 不可 Dump/刪除
4.3.8. EXT2_NOATIME_FL ? 不更新 .i_atime
4.3.9. EXT2_DIRTY_FL ? 髒的
4.3.10. EXT2_COMPRBLK_FL ? 壓縮的塊
4.3.11. EXT2_NOCOMPR_FL ?Raw方式訪問壓縮的數據
4.3.12. EXT2_ECOMPR_FL ? 壓縮錯誤
4.3.13. EXT2_BTREE_FL - B-Tree 格式目錄
4.3.14. EXT2_INDEX_FL - Hash 索引目錄
4.3.15. EXT2_IMAGIC_FL -
4.3.16. EXT2_JOURNAL_DATA_FL ? 日誌文件數據
4.3.17. EXT2_RESERVED_FL ? 保留
A. 鳴謝
B．譯者後記
表格列表
1-1. EXT2_ERRORS 值
1-2. EXT2_OS 值
1-3. EXT2 修訂版本
1-4. EXT2_*_INO值
1-5. EXT2_S_I值
2-1. EXT2_FT值
4-1. 行為控制標記
圖片列表
1-1. 磁碟的元數據布局
1-2. 20mb 分區元數據布局
1-3. 超級塊結構
1-4. group_desc 結構
1-5. inode 結構
1-6. inode osd2 結構: Hurd
1-7. inode osd2 結構: Linux
1-8. inode osd2 結構: Masix
2-1. 目錄入口
2-2. 目錄數據布局例子
2-3. 索引目錄的性能
3-1. inode計算例子
4-1. ext2_xattr_header 結構
4-2. ext2_xattr_header 結構
關於本書
本書的最新版本下載的URL：http://www.freesoftware.fsf.org/ext2-doc/
本書的目的在於提供關於The Second Extended File System即Ext2文件系統的入門指南。本書假定讀者熟悉關於文件系統的相關概念（如：文件，目錄，分區等等）。
實現Ext2的驅動程序並非一件易事，其最大的困難正好就是相關文檔資料的缺乏。而目前網上關於Ext2內部布局的文檔資料只不過是作為Linux sourcesr的補充而寫的，並沒有完整、系統的關於Ext2內部布局的文檔資料。
本文檔資料的目的正是為解決此問題而生，希望它能對有此需要的人有所幫助。
Unless otherwise stated, all values are stored in little endian byte order.
Chapter 1. 磁碟組織
在使用The Second Extended File System前首先要明確的是所有的元數據（Meta-data）結構的大小均基於「塊（block）」而不是「扇區（sector）」。塊的大小是可變的，依賴於文件系統的大小。例如在一個軟盤塊的大小為1KB（2個扇區），而在一個10G的分區里塊的大小通常為4KB或8KB（分別為8或16個扇區）。
每一個塊可以進一步劃分為「段（fragments）」，但我見過一個段的大小與塊的大小不相匹配的文件系統。儘管常識告訴我段與塊不相匹配是不合理的。
除了超級塊（superblock）外，所有的元數據結構都以塊為基準調整大小。這裡有一點要注意，與軟盤相比在安裝任何其它的文件系統時，inode表塊（Inode Tabel Block）在塊大小為4KB比在塊大小為1KB的文件系統里可以容納更多的入口，這是當訪問這樣的一個特定結構時需要注意的。
下一步要明確的是文件系統還劃分了「塊組（block groups）」。在一張軟盤裡只使用一個塊組包含文件系統里所有的塊，但在一個10G的硬碟分區里將劃分為30個這樣的包含有一定數量塊的塊組。
在每個塊組的開始多個元數據結構且在一個結構里描述有另一個的位置，更重要的是，元數據結構定義了當前文件系統的狀態。下面是在一張軟盤的Ext2文件系統的磁碟組織：
Figure 1-1. 軟盤的元數據布局
offset # of blocks description
偏移 塊號 描述
-------- ----------- -----------
0 1 boot record 引導記錄
-- block group 0 ?
塊組 0
(1024 bytes) 1 superblock 超級塊
2 1 group descriptors 塊組描述符
3 1 block bitmap 塊點陣圖
4 1 inode bitmap inode點陣圖
5 23 inode table inode 表
28 1412 data blocks 數據塊
下面是一個20MB Ext2文件系統的磁碟組織：
Figure 1-2. 20mb 分區元數據布局
offset # of blocks description
-------- ----------- -----------
0 1 boot record
-- block group 0 --
(1024 bytes) 1 superblock
2 1 group descriptors
3 1 block bitmap
4 1 inode bitmap
5 214 inode table
219 7974 data blocks
-- block group 1 --
8193 1 superblock 備份
8194 1 group descriptors 備份
8195 1 block bitmap
8196 1 inode bitmap
8197 214 inode table
8408 7974 data blocks
-- block group 2 --
16385 1 block bitmap
16386 1 inode bitmap
16387 214 inode table
16601 3879 data blocks
只要你了解磁碟基本的信息，磁碟的布局是可以預知的；塊的大小，每個塊組包含多少塊，每個塊組的inode數量等這些信息均可以在超級塊結構里找到或通過計算得到的。
沒有超級塊的信息，磁碟將不可用；所以只要磁碟上的空間允許，在磁碟上將有一個或多個超級塊的備份。
塊點陣圖與inode點陣圖用於識別哪些塊和哪些inode入口是可用的。各種各樣的文件將保存在數據塊里。注意：在Ext2里目錄也被視為文件，在下面我們將詳細對此進行描述。
為兼容不同的Ext2實現，在不同結構里的一些因為特定的操作系統而有所差別的區域，將在適當的時候給予簡要的說明。
1.1. 超級塊
超級塊這個結構里包含了磁碟里Ext2 文件系統屬性里最基本的信息。它的布局如下：
Figure 1-3. 超級塊結構
offset size description
偏移 大小 描述
------- ------- -----------
0 4 s_inodes_count
4 4 s_blocks_count
8 4 s_r_blocks_count
12 4 s_free_blocks_count
16 4 s_free_inodes_count
20 4 s_first_data_block
24 4 s_log_block_size
28 4 s_log_frag_size
32 4 s_blocks_per_group
36 4 s_frags_per_group
40 4 s_inodes_per_group
44 4 s_mtime
48 4 s_wtime
52 2 s_mnt_count
54 2 s_max_mnt_count
56 2 s_magic
58 2 s_state
60 2 s_errors
62 2 s_minor_rev_level
64 4 s_lastcheck
68 4 s_checkinterval
72 4 s_creator_os
76 4 s_rev_level
80 2 s_def_resuid
82 2 s_def_resgid
-- EXT2_DYNAMIC_REV 細節 --
84 4 s_first_ino
88 2 s_inode_size
90 2 s_block_group_nr
92 4 s_feature_compat
96 4 s_feature_incompat
100 4 s_feature_ro_compat
104 16 s_uuid
120 16 s_volume_name
136 64 s_last_mounted
200 4 s_algo_bitmap
-- 性能提示 --
204 1 s_prealloc_blocks
205 1 s_prealloc_dir_blocks
206 2 - (alignment)
-- 日誌支持 --
208 16 s_journal_uuid
224 4 s_journal_inum
228 4 s_journal_dev
232 4 s_last_orphan
-- 未用 --
236 788 - (填充)
1.1.1. s_inodes_count
32bit的值表示所有inode的總數，包括文件系統里已用和未用的。
1.1.2. s_blocks_count
32bit的值表示塊的總數，包括文件系統里已用和未用的。
1.1.3. s_r_blocks_count
32bit的值表示為超級用戶保留的塊的總數。這是非常有用的：當某個用戶有意或無意用數據充滿了整個文件系統的空間時，超級用戶可以用這些保留的只有超級用戶可用的空間來保存或編輯配置文件來解決相關問題。
1.1.4. s_free_blocks_count
32bit的值表示未用的塊的總數，包括保留的塊（查看s_r_blocks_count）。這是所有塊組裡的所有未用的塊的總數。
1.1.5. s_free_inodes_count
32bit的值表示未用的inode的總數。這是所有塊組裡的所有未用的inode的總數。
1.1.6. s_first_data_block
32bit的值識別第一個數據塊，也就是包含超級塊結構的塊ID。
注意：這個值在塊大小大於1KB的文件系統里總是0，而在塊大小為1KB的文件系統里總是1。因為超級塊總是在磁碟的第1024個位元組開始的，也就正好是第三個扇區的第一個位元組。
1.1.7. s_log_block_size
塊的大小用1024算術左移以此值為位數而得出。這個值一定是正值。
block size = 1024 << s_log_block_size;
1.1.8. s_log_frag_size
段的大小用1024算術左移以此值為位數而得。注意：若此值為負值則算術右移。
if( positive )
fragment size = 1024 << s_log_frag_size;
else
fragment size = 1024 >> -s_log_frag_size;
1.1.9. s_blocks_per_group
32bit的值表示每塊組裡塊的總數。這個值與s_first_data_block聯合決定塊組的邊界。
1.1.10. s_frags_per_group
32bit的值表示每塊組裡段的總數。它也用於決定每個塊組裡塊點陣圖的大小。
1.1.11. s_inodes_per_group
32bit的值表示每塊組inode的總數。也用於決定每塊組裡inode點陣圖的大小。
1.1.12. s_mtime
Unix時間，在POSIX定義，文件系統最近被安裝的時間。
1.1.13. s_wtime
Unix時間，在POSIX定義，文件系統最近被訪問的時間。
1.1.14. s_mnt_count
32bit的值表示文件系統從最近一次完整校驗后被安裝的次數。
1.1.15. s_max_mnt_count
32bit的值表示在被完整校驗前文件系統還可以被安裝的最大次數。
1.1.16. s_magic
16bit的值用於識別文件系統為Ext2。此值通常固定為0xEF53。
1.1.17. s_state
16bit的值表示文件系統的狀態。當文件系統被安裝，此狀態被設EXT2_ERROR_FS。當文件系統沒有被安裝，此值是EXT2_VALID_FS 或在文件系統沒有被正確卸載時為EXT2_ERROR_FS。
1.1.18. s_errors
16bit的值表示當文件系統被發現錯誤時文件系統驅動程序的決策。其值如下：
Table 1-1. EXT2_ERRORS 值
EXT2_ERRORS_CONTINUE 1 繼續，猶如沒有錯誤
EXT2_ERRORS_RO 2 重新安裝為只讀模式
EXT2_ERRORS_PANIC 3 引起一個內核應急常式
EXT2_ERRORS_DEFAULT 可變 在0.5版本里，此值等同於EXT2_ERRORS_CONTINUE
1.1.19. s_minor_rev_level
16bit的值在修訂版本級別(Revision Level)里識別局部修訂級別。
1.1.20. s_lastcheck
Unix時間，在POSIX定義，文件系統最近被檢查的時間。
1.1.21. s_checkinterval
文件系統被檢查的最大Unix時間間隔，在POSIX定義。
1.1.22. s_creator_os
32bit識別生成文件系統的操作系統。定義如下：
Table 1-2. EXT2_OS 值
EXT2_OS_LINUX 0 Linux
EXT2_OS_HURD 1 Hurd
EXT2_OS_MASIX 2 MASIX
EXT2_OS_FREEBSD 3 FreeBSD
EXT2_OS_LITES4 4 Lites
1.1.23. s_rev_level
32bit修訂級別值。目前有2個值被定義：
Table 1-3. EXT2 修訂
EXT2_GOOD_OLD_REV 0 原始的格式
EXT2_DYNAMIC_REV 1 使用動態inode大小的V2格式
1.1.24. s_def_resuid
16bit值用於定義保留塊的默認用戶ID。
1.1.25. s_def_resgid
16bit值用於定義保留塊的默認組ID。
1.1.26. s_first_ino
32bit值作為標準文件的第一個可用inode的索引。在非動態文件系統修訂版本里，每一個非保留inode固定為11。在引入文件系統的動態修訂版本里這個值是可變的。
1.1.27. s_inode_size
16bit值表示inode結構的大小。在非動態文件系統修訂版本里這個值假定為128。
1.1.28. s_block_group_nr
16bit值表示保存有超級塊的塊組號。可以用此值找到超級塊備份來重建文件系統。
1.1.29. s_feature_compat
兼容特性的32bit位掩碼。文件系統實現里不一定都支持，但對元數據無影響。（以後對此將有更多的信息加入）
1.1.30. s_feature_incompat
不兼容特性的32bit位掩碼。如果缺少某些必需的特性支持，文件系統實現將拒絕安裝此文件系統。（以後對此將有更多的信息加入）
1.1.31. s_feature_ro_compat
「只讀」特性的32bit位掩碼。如果缺少某些必需的特性支持，文件系統實現將以只讀模式安裝此文件系統。（以後對此將有更多的信息加入）
1.1.32. s_uuid
128bit值用於描述卷ID。應該儘可能在每個文件系統格式有唯一的值。
1.1.33. s_volume_name
16bytes卷名，大多數沒用。有效的卷名只能由ISO-Latin-1字元組成，以0結束。
1.1.34. s_last_mounted
64bytes表示文件系統最近被安裝的目錄路徑。一般不用，它可以在命令行下不指定安裝目錄路徑時自動查找安裝點。因為兼容性，目錄路徑以0結束。有效的目錄路徑由ISO-Latin-1字元組成。
1.1.35. s_algo_bitmap
32bit值用於壓縮演算法決定使用何種壓縮方式。（對於此欄位我沒有更多的理解，如果你對此欄位熟悉可以將你知道的信息發送給我，謝謝）。
1.2. 塊組描述符
塊組描述符（Goup Descriptors）是一組group_desc結構，每一組描述一個「塊組」，給出塊組的inode表，塊和inode點陣圖的位置及其它一些有用的信息。
塊組描述符緊接於超級塊結構所在塊的後面第一個塊。這裡有一個塊組描述符的例子：
Figure 1-4. group_desc 結構
offset size description
------- ------- -----------
0 4 bg_block_bitmap
4 4 bg_inode_bitmap
8 4 bg_inode_table
12 2 bg_free_blocks_count
14 2 bg_free_inodes_count
16 2 bg_used_dirs_count
18 2 bg_pad
20 12 bg_reserved
在文件系統里每一個塊組都建立有group_desc這樣的結構。在文件系統里每個這樣的結構描述一個單一的「塊組」，而每個這樣的結構只描述它所在的塊組的相關信息。每個「塊組描述符表（Group Descriptor Table）」包含所有塊組的所有信息。
所有可用的「塊ID」是唯一的。
1.2.1. bg_block_bitmap
32bit值為當前塊組指出「塊點陣圖(Block Bitmap)」的第一個塊的塊ID。
1.2.2. bg_inode_bitmap
32bit值為當前塊組指出「inode點陣圖(Inode Bitmap)」的第一個塊的塊ID。
1.2.3. bg_inode_table
32bit值為當前塊組指出「inode表(Inode Table)」的第一個塊的塊ID。
1.2.4. bg_free_blocks_count
16bit值表示當前塊組裡未用的塊的總數。
1.2.5. bg_free_inodes_count
16bit值表示當前塊組裡未用的inode的總數。
1.2.6. bg_used_dirs_count
16bit值表示當前塊組分配給目錄的inode 總數。
1.2.7. bg_pad
16bit用於填充32bit結構。
1.2.8. bg_reserved
3個連續的32bit值為將來的實現的應用保留。
1.3. 塊點陣圖
「塊點陣圖（Block Bitmap）」通常位於塊組的第一個塊，若存在備份超級塊則在第二個塊。它的實際位置可以通過在塊組描述符里的「bg_block_bitmap」得知。
塊點陣圖里的每一位指出在該塊組內的所對應塊的當前狀態，其中1表示「已用」而0表示「未用」。在該塊組裡的第一個塊被位元組0的第0位標記，第二個塊被位元組0的第1位標記。第8個塊則對應位元組0的第7位而第9個塊就對應位元組1里的第0位。以此類推。
1.4. Inode 點陣圖
「Inode點陣圖（Inode Bitmap）」的作用類同於「塊點陣圖」，不同的是每一個位對應「inode表」里的一個inode而不是塊。
每一個塊組有一個inode點陣圖，它的位置可以通過塊組描述符里的「bg_inode_bitmap」得知。
當inode表被建立時，所有的保留inode被標記為已用。在「Good Old修訂版本」里對應inode點陣圖里的前11位。
1.5. Inode 表
「Inode表（Inode Table）」用於跟蹤定位每個文件；文件的位置，大小，類型和訪問許可權均保存在inode。然而文件名並不保存在inode里，在inode表裡，是依賴文件的inode號來管理所有的文件的。
一個塊組只有一個inode表且此表可以通過相關聯的塊組描述符里的「bg_inode_table」 得知。一個表共有s_inodes_per_group個inode。
每個inode包含關於在系統里單個物理文件的信息。一個文件可以是一個目錄，一個套接字，一個緩衝區，一個字元或者是塊設備，符號連接或一個普通文件。所以，一個inode可以看作是與一個實體相關的信息塊，描述它在磁碟的位置、大小、屬主。一個inode如下：
Figure 1-5. inode 結構
offset size description
------- ------- -----------
0 2 i_mode
2 2 i_uid
4 4 i_size
8 4 i_atime
12 4 i_ctime
16 4 i_mtime
20 4 i_dtime
24 2 i_gid
26 2 i_links_count
28 4 i_blocks
32 4 i_flags
36 4 i_osd1
40 15 x 4 i_block
100 4 i_generation
104 4 i_file_acl
108 4 i_dir_acl
112 4 i_faddr
116 12 i_osd2
Inode表的前面幾個入口是保留的。在EXT2_GOOD_OLD_REV保留了11個入口，而在較新的EXT2_DYNAMIC_REV里保留的入口數量在超級塊結構里的s_first_ino指出。下面是已知的保留inode入口的列表：
Table 1-4. EXT2_*_INO 值
EXT2_BAD_INO 0x01 壞塊inode
EXT2_ROOT_INO 0x02 根目錄inode
EXT2_ACL_IDX_INO 0x03 ACL 索引inode (抗議?)
EXT2_ACL_DATA_INO 0x04 ACL 數據 inode (抗議?)
EXT2_BOOT_LOADER_INO 0x05 引導程序inode
EXT2_UNDEL_DIR_INO 0x06 反刪除目錄inode
1.5.1. i_mode
16bit值指出文件格式和訪問許可權。這裡有可能的值，且可以使用不同方式組合起來：
Table 1-5. EXT2_S_I 值
-- 文件格式 --
EXT2_S_IFMT 0xF000 格式掩碼
EXT2_S_IFSOCK 0xC000 套接字
EXT2_S_IFLNK 0xA000 符號連接
EXT2_S_IFREG 0x8000 普通文件
EXT2_S_IFBLK 0x6000 塊設備
EXT2_S_IFDIR 0x4000 目錄
EXT2_S_IFCHR 0x2000 字元設備
EXT2_S_IFIFO 0x1000 fifo
-- 訪問許可權 --
EXT2_S_ISUID 0x0800 SUID
EXT2_S_ISGID 0x0400 SGID
EXT2_S_ISVTX 0x0200 粘著位
EXT2_S_IRWXU 0x01C0 用戶訪問許可權掩碼
EXT2_S_IRUSR 0x0100 讀
EXT2_S_IWUSR 0x0080 寫
EXT2_S_IXUSR 0x0040 執行
EXT2_S_IRWXG 0x0038 組訪問許可權掩碼
EXT2_S_IRGRP 0x0020 讀
EXT2_S_IWGRP 0x0010 寫
EXT2_S_IXGRP 0x0008 執行
EXT2_S_IRWXO 0x0007 其他用戶訪問許可權
EXT2_S_IROTH 0x0004 讀
EXT2_S_IWOTH 0x0002 寫
EXT2_S_IXOTH 0x0001 執行
1.5.2. i_uid
16bit文件相關聯的用戶ID。
1.5.3. i_size
32bit值表示文件的大小（以位元組為單位）。
1.5.4. i_atime
32bit值指出文件最近被訪問的時間距離1970年1月1日的秒數。
1.5.5. i_ctime
32bit值指出文件建立的時間距離1970年1月1日的秒數。
1.5.6. i_mtime
32bit值指出文件最近被修改的時間距離1970年1月1日的秒數。
1.5.7. i_dtime
32bit值指出文件被刪除的時間距離1970年1月1日的秒數。這很重要，這個值總是0除非文件被刪除。
1.5.8. i_gid
16bit值指出屬組曾經訪問過此文件。
1.5.9. i_links_count
16bit值表示此inode被連接的次數。
1.5.10. i_blocks
32bit值表示與此文件數據關聯的保留塊的個數。包括當前已經使用了的和當前為滿足文件增大所需要的。
需要指出：此值表示大小為512bytes的塊的個數而不是在超級塊里指定大小的塊的個數。所以若一個文件系統的塊的大小是1024bytes，它的.i_blocks的值是2。
1.5.11. i_flags
32bit值表示當在此inode訪問數據時Ext2實現的行為。（詳細查看行為標記部分。）
1.5.12. i_osd1
32bit操作系統依賴的值。
1.5.12.1. Hurd
32bit的「翻譯者」標籤。
1.5.12.2. Linux
32bit目前保留。
1.5.12.3. Masix
32bit目前保留。
1.5.13. i_block
用於定位存貯普通文件的塊的數組。每一個入口是一個32bit的塊號。在此數組的前12個入口是直接塊號，可直接用於定位存貯此文件的前12個塊。
第13個入口是一級間接塊號。此塊號指向另一個包含有存貯這個文件其它塊號的塊。即第13個入口給出的塊是用於存貯此文件的塊號，這些塊號可直接定位存貯此文件的塊。
每14個入口是一個二級間接塊號。塊號指向一個特殊的數據塊，此數據塊存貯一級間接塊號數組，通過這些數組的間接塊號可以找到存貯直接定位存貯此文件塊號的塊（就是類似於第13個入口所指向的塊）。
每15個入口是一個三級間接塊號。它是一個指向一個存貯二級間接塊號數組的塊，等等。
每個一級間接/二級間接/三級間接塊數組均包含有同樣數量的32bit塊號（如果文件足夠大）的入口（充滿整個塊）。
譯者：對i_block的理解很重要，特別對於數據恢復。它們的關係的如下圖：
1.5.14. i_generation
32bit值用於表示文件版本（用於NFS）。
1.5.15. i_file_acl
32bit值用於表示包含擴展屬性的塊號。在以前的修訂版本其值總是0。
關於ACL for Digital UNIX全面的描述可以訪問：
http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R2D-TET1_html/sec.c27.html
1.5.16. i_dir_acl
32bit值用於表示文件的「High Size」。 在以前的修訂版本其值總是0。
1.5.17. i_faddr
32bit值用於表示文件最後一個段的位置。
1.5.18. i_osd2
96bit操作系統依賴的結構。
1.5.18.1. Hurd
Figure 1-6. inode osd2 結構: Hurd
offset size description
------- ------- -----------
0 1 h_i_frag
1 1 h_i_fsize
2 2 h_i_mode_high
4 2 h_i_uid_high
6 2 h_i_gid_high
8 4 h_i_author
1.5.18.1.1. h_i_frag
8bit段號。
1.5.18.1.2. h_i_fsize
8bit段大小。
1.5.18.1.3. h_i_mode_high
1.5.18.1.4. h_i_uid_high
用戶ID的高16bit。
1.5.18.1.5. h_i_gid_high
組ID的高16bit。
1.5.18.1.6. h_i_author
1.5.18.2. Linux
Figure 1-7. inode osd2 結構: Linux
offset size description
------- ------- -----------
0 1 l_i_frag
1 1 l_i_fsize
2 2 保留
4 2 l_i_uid_high
6 2 l_i_gid_high
8 4 保留
1.5.18.2.1. l_i_frag
8bit段號。
1.5.18.2.2. l_i_fsize
8bit段大小。
1.5.18.2.3. l_i_uid_high
用戶ID的高16bit。
1.5.18.2.4. l_i_gid_high
組ID的高16bit。
1.5.18.3. Masix
Figure 1-8. inode osd2 結構: Masix
offset size description
------- ------- -----------
0 1 m_i_frag
1 1 m_i_fsize
2 10 保留
1.5.18.3.1. m_i_frag
8bit段號。
1.5.18.3.2. m_i_fsize
8bit段大小。
1.6. 數據塊
數據塊（Data Block）用於存貯大量的文件的內容，包括目錄表，擴展屬性，符號連接，等等。
Chapter 2. 目錄結構
目錄是作為文件存貯的。它在ext2_inode.i_mode里表示EXT2_S_IFDIR值的文件格式位里確定。
其中根目錄總是在inode表的每二個入口（EXT2_ROOT_INO的值是2）。其它的子錄可以在根目錄文件的內容里定位。
2.1. 目錄文件格式
Figure 2-1. 目錄入口
offset size description
------- ------- -----------
0 4 inode
4 2 rec_len
6 1 name_len
7 1 file_type
8 ... name
在早期的Ext2實現里name_len是16bit的值，但自從此值存貯在Intel(little-endian)位元組命令和在大多數Ext2實現的文件名受到255字元的限制時，允許一個位元組用於循環利用。
2.1.1. inode
32bit文件入口的inode號。如果值為0表示此入口未用。
2.1.2. rec_len
16bit無符號值表示從當前目錄入口到下一個目錄入口的偏移。
2.1.3. name_len
8bit無符號值表示文件名包含的字元數。
2.1.4. file_type
8bit無符號值表示文件類型。在早期的實現里這些值為0。當前這些值的定義為：
Table 2-1. EXT2_FT 值
EXT2_FT_UNKNOWN 0 未知
EXT2_FT_REG_FILE 1 普通文件
EXT2_FT_DIR 2 目錄
EXT2_FT_CHRDEV 3 字元設備
EXT2_FT_BLKDEV 4 塊設備
EXT2_FT_FIFO 5 FIFO
EXT2_FT_SOCK 6 套接字
EXT2_FT_SYMLINK 7 符號連接
EXT2_FT_MAX 8 MAX
2.1.5. name
入口名稱（文件名）。使用ISO-Latin-1字元。
2.2. 目錄例子
這裡是在我系統里的一用戶Home目錄的例子：
$ ls -1a /home/eks
.
..
.bash_profile
.bashrc
mbox
public_html
tmp
下面列出的數據可以在存貯設備里找到：
Figure 2-2. 目錄例子數據布局
offset size description
------- ------- -----------
0 4 inode number (783362) inode號
4 2 record length (9) 記錄長度
6 1 name length (1) 文件名長度
7 1 file type (EXT2_FT_DIR) 文件類型
8 1 name (.) 文件名
9 4 inode number (1109761)
13 2 record length (10)
15 1 name length (2)
16 1 file type (EXT2_FT_DIR)
17 2 name (..)
19 4 inode number (783364)
23 2 record length (21)
25 1 name length (13)
26 1 file type (EXT2_FT_REG_FILE)
27 13 name (.bash_profile)
40 4 inode number (783363)
44 2 record length (15)
46 1 name length (7)
47 1 file type (EXT2_FT_REG_FILE)
48 7 name (.bashrc)
55 4 inode number (783377)
59 2 record length (12)
61 1 name length (4)
62 1 file type (EXT2_FT_REG_FILE)
63 4 name (mbox)
67 4 inode number (783545)
71 2 record length (19)
73 1 name length (11)
74 1 file type (EXT2_FT_DIR)
75 11 name (public_html)
86 4 inode number (669354)
90 2 record length (11)
92 1 name length (3)
93 1 file type (EXT2_FT_DIR)
94 3 name (tmp)
97 4 inode number (0)
101 2 record length (3999)
103 1 name length (0)
104 1 file type (EXT2_FT_UNKNOWN)
105 0 name ()
需要注意：在一些實現里，為在主處理器上獲得更好的性能而在目錄入口進行填充，重要的是將使用記錄長度而不使用文件名長度來查找下一條記錄。
2.3. 索引目錄格式
為提高文件系統的性能，建立一個Hash索引，可快速定位需要的文件。
如果使用索引目錄格式（Indexed Directory Format）時，在behaviour control flags里的EXT2_INDEX_FL位將被設置。
2.3.1. 索引結構
根目錄的索引樹（Index Tree）在文件的第0塊。為索引樹的第二層保留了1到511個塊（在4K/塊的文件系統）。目錄的葉塊(Leaf Block)添加於第512塊開始處，因此文件的尾部看起來就像一個普通的Ext2目錄並可以直接被ext2_readdir處理。如果目錄數小於90K個文件時在第1塊到第511塊里將有一片空白區，所以一個空的目錄只有2個塊，儘管它在目錄列表裡看起來大小是2M。
所以一個索引目錄文件如下：
0: Root index block
1: Index block/0
2: Index block/0
...
511: Index block/0
512: Dirent block
513: Dirent block
...
每個索引塊包含如下結構的512個索引入口：
hash, block
Hash是將任意長度的一塊數據轉換為一個定長的、不可逆轉的、唯一的32bit數據，而塊是一個葉塊的索引的邏輯塊號，依賴於樹的層次。
第0個索引入口的hash值是不需要的，因為它總是可以在層次里獲得，因此它用於記錄在一個索引塊里索引入口的數量。這裡給出了一個很好的分支因子(Branching Factor)：512，這樣使查找有規則性獲得的好處多於因此獲得的性能上的改善。（另一方面，巨大的分支因子能獲得更好的性能。）
根索引塊具有和其它索引塊一樣的格式，其中前8個位元組為頭部而保留。
1byte頭長度（默認：8）
1byte索引類型（默認：0）
1byte hash版本（默認：0）
1byte樹深度（默認：1）
在不同的補丁里對頭部的處理有些許不同。通常，實現里只有一個單一的索引樹（根）。已經證明這樣已足夠處理大約90，000個入口，在目前來說是足夠的。當在樹里加入第二層時可以處理的入口數量為50,000,000個入口，可以看出目前沒有必要使用N層索引，而且第三層也許永遠也用不上。就算需要，目前的設計也是支持的。
2.3.2. 查找演算法
查找的演算法如下：
- 計算文件名的Hash值
- 讀取索引根
- 使用二制查找（在目前的代碼使用線性查找）包含有目標hash值的第一個索引或葉塊（依樹的順序）
- 重複上面的查找直到樹的最底層
- 讀取葉目錄的入口塊並在普通的Ext2目錄塊里進行查找
- 如果找到了文件名，返回其目錄入口和緩衝區
- 另外，如果設置了下一目錄的入口衝突位，則在查找成功的塊里繼續查找
一般來說，文件有2個邏輯塊將要被訪問，一個或兩個元數據索引塊。其效果就是只要元數據索引塊沒有撤出cache那麼訪問元數據索引塊的時間在磁碟訪問時間裡幾乎可以被忽略。所以移動整個目錄到頁面cache里可以減少查找佔用的CPU開銷。
2.3.3. 插入演算法
往目錄里插入一個新的入口比查找複雜得多，當葉塊滿了就需要拆分葉塊，並且需滿足的條件是允許Hash Key衝突(Hash Key Collision)被有效且可靠的處理。這裡我將概要的提及：
- 類似查找一樣探查索引
- 如果目標葉塊已滿，拆分葉塊並標記塊將接受新的入口
- 使用普通的Ext2目錄入口插入代碼往葉塊里插入新的入口。
關於拆分和hash衝突處理的細節比較混亂，如誰能詳述這方面的內容我樂意將這些內容加入到文檔中。
2.3.4. 拆分
簡要的講，當我們往一個已經滿了的葉inode里插入新的入口時，葉必需被拆分（Split），且它們共享的hash空間必需被分割。最直截了當的做法是以hash值排序入口且在序列的中部拆分。這個操作被記錄(number_of_entries_in_leaf)且使用高效的排序程序時開銷並不大。儘管在平均性能比最壞性能重要時Quicksort也可以做得很好，但我還是使用Combsort完成它。
An alternative approach would be just to guess a median value for the hash key, and the partition could be done in linear time, but the resulting poorer partitioning of hash key space outweighs the small advantage of the linear partition algorithm. In any event, the number of entries needing sorting is bounded by the number that fit in a leaf.
2.3.5. Key 衝突
Some complexity is introduced by the need to handle sequences of hash key collisions. It is desireable to avoid splitting such sequences between blocks, so the split point of a block is adjusted with this in mind. But the possibility still remains that if the block fills up with identically-hashed entries, the sequence may still have to be split. This situation is flagged by placing a 1 in the low bit of the index entry that points at the sucessor block, which is naturally interpreted by the index probe as an intermediate value without any special coding. Thus, handling the collision problem imposes no real processing overhead, just come extra code and a slight reduction in the hash key space. The hash key space remains sufficient for any conceivable number of directory entries, up into the billions.
2.3.6. Hash 功能
The exact properties of the hash function critically affect the performance of this indexing strategy, as I learned by trying a number of poor hash functions, at times intentionally. A poor hash function will result in many collisions or poor partitioning of the hash space. To illustrate why the latter is a problem, consider what happens when a block is split such that it covers just a few distinct hash values. The probability of later index entries hashing into the same, small hash space is very small. In practice, once a block is split, if its hash space is too small it tends to stay half full forever, an effect I observed in practice.
After some experimentation I came up with a hash function that gives reasonably good dispersal of hash keys across the entire 31 bit key space. This improved the average fullness of leaf blocks considerably, getting much closer to the theoretical average of 3/4 full.
But the current hash function is just a place holder, waiting for an better version based on some solid theory. I currently favor the idea of using crc32 as the default hash function, but I welcome suggestions.
Inevitably, no matter how good a hash function I come up with, somebody will come up with a better one later. For this reason the design allows for additional hash functiones to be added, with backward compatibility. This is accomplished simply, by including a hash function number in the index root. If a new, improved hash function is added, all the previous versions remain available, and previously created indexes remain readable.
Of course, the best strategy is to have a good hash function right from the beginning. The initial, quick hack has produced results that certainly have not been disappointing.
2.3.7. 性能
OK，到了這裡毫無疑問你最關心的將是索引目錄的性能問題。簡要的說，其性能比普通的Ext2有極大的提高。如果在很小的目錄數量上其性能並不比標準的Ext2好多少，但隨目錄的數量的增長標準Ext2的性能呈指數下降，而在htree-enhanced Ext2里只是呈線性下降。
Uli Luckas 運行benchmarks測試在不同目錄數量級里建立10，000到90，000個文件所需要的時間。結果是可喜的：建立文件所用的總時間在索引目錄里呈線性增長，而與之對比的普通Ext2則呈指數增長。
時間如下：
Figure 2-3. 索引目錄的性能
索引目錄 普通目錄
======= ======
10000 Files: 0m1.350s 0m23.670s
20000 Files: 0m2.720s 1m20.470s
30000 Files: 0m4.330s 3m9.320s
40000 Files: 0m5.890s 5m48.750s
50000 Files: 0m7.040s 9m31.270s
60000 Files: 0m8.610s 13m52.250s
70000 Files: 0m9.980s 19m24.070s
80000 Files: 0m12.060s 25m36.730s
90000 Files: 0m13.400s 33m18.550s
其圖形化結果在：http://www.innominate.org/~phillips/htree/performance.png
所有的這些測試是受CPU限制的，若非如此可能會有意外的結果。目錄可以很容易適應cache，而在標準Ext2里受限制的是在緩衝區cache里查找目錄塊，低級的目錄入口掃描。而在Hash tree索引里只有一個開銷被考慮，所有的這些都有極好的控制。儘管如此，還是明顯地可以對性能進行優化：
- 在內部的索引inode里使用二進位查找替換線性查找。
- 如果在葉塊里只有一個目錄，繞過索引檢測，直接訪問塊。
- 更改映射目錄到緩衝區cache為映射目錄到頁面cache。
所有的這些優化可以明顯的提高性能，儘管性能不可能從N**2飛躍到Log512(n),~N，但優化后我們可以看到性能被成倍或更好的提高。
當目錄大到要使用索引樹的第二層時性能會有所折扣。因為它們的快速緩衝將很小。遍歷目錄元數據索引塊要很大的開銷，然而再者，可以通過將目錄塊放入頁面cache里來減少這些開銷。
通常，我們讀或寫一個目錄入口會遍歷3個塊，如果數量增加到4-5將是一個巨大的目錄。但比起普通Ext2來說性能下降幾乎微不足道，因為在同樣情形下普通Ext2要遍歷幾百個塊。
Chapter 3. Inode, 文件標識符
每個文件，目錄，符號連接，特殊設備，或任何其它保存在Ext2文件系統里的東東，都是通過其inode來標識的。如果你知道所讀取的文件的inode號，甚至你不知道文件名，你仍可以在磁碟上定位並讀取它。
3.1. Inode 號
Inode號是在inode表裡一個inode結構的一個索引。Inode表的大小在格式化時就固定下來，它被設置為儘可能容納最多的入口。儘管所需的入口數量很大，但表的大小是足以滿足需求的，況且它還被平均地拆分後放在所有的「塊組」里（查看Chapter 1獲得更多說明）。
3.2. 定位inode結構
在超級塊結構里的s_inodes_per_group欄位告訴我們一個塊組裡定義有多少個inode。以此我們可以知道inode 1是在inode表裡定義的第一個inode，所以可以有以下公式：
group = (inode - 1) / s_inodes_per_group
為定位塊組的inode表哪裡包含了要查找的inode入口可用以下公式：
index = (inode - 1) % s_inodes_per_group
使用index在inode表裡查找inode入口。這裡有一組例子，你可以用以測試你自己的Ext2實現：
Figure 3-1. inode計算例子
s_inodes_per_group = 1712
inode 號 計算
------------ -----------
1 group = (1 - 1) / 1712 = 0
index = (1 - 1) % 1712 = 0
2 group = (2 - 1) / 1712 = 0
index = (2 - 1) % 1712 = 1
963 group = (963 - 1) / 1712 = 0
index = (963 - 1) % 1712 = 962
1712 group = (1712 - 1) / 1712 = 0
index = (1712 - 1) % 1712 = 1711
1713 group = (1713 - 1) / 1712 = 1
index = (1713 - 1) % 1712 = 0
3424 group = (3424 - 1) / 1712 = 1
index = (3424 - 1) % 1712 = 1711
3425 group = (3425 - 1) / 1712 = 2
index = (3425 - 1) % 1712 = 0
正如你所熟悉的，index 0意味著第一個入口。為何以0開始，而不是使用1開始的目的在於可以將此值乘於結構的大小就得到文件在內存或磁碟里的最終偏移。
3.3. 定位Inode表
如Section 3.1所介紹的，inode表被平均地拆分後放在各個塊組裡。如果一個文件系統允許有數千個inode，拆分為5個塊組，那在每個部分的inode表裡將有200個inode。Figure 3-1已經舉例說明了類似的分佈。
每個部分的inode表可以通過所在塊組的塊組描述符里的bg_inode_table欄位里被定位。
Chapter 4. 文件屬性
文件的（包括目錄，符號連接，設備……）屬性大多數是位於文件inode里的標準屬性。而除此之外還有一些不在inode里的擴展屬性。
4.1. 標準屬性
4.1.1. SUID, SGID 與 -rwxrwxrwx
在這裡就不再對此有過多的描述，它們在ext2_inode.i_mode里的SGID和SUID位里有詳細說明。
4.1.2. 文件大小
文件的大小可以通過查看ext2_inode.i_size欄位得知。
4.1.3. 屬主與屬組
在多數的實現里，屬主與屬組為16bit的值，但在最新的Linux和Hurd的實現里它們的屬主與屬組ID為32bit。當使用16bit值時，只有「低位」部分起作用，而使用32bit值時，欄位的「低位」與「高位」部分均起作用，其中「高位」部分經左移16位后與「低位」部分相加。
屬主與屬組ID的「低位」部分分別位於ext2_inode.i_uid與ext2_inode.i_gid。
屬主與屬組ID的「高位」部分分別位於ext2_inode.osd2.hurd.h_i_uid_high和ext2_inode.osd2.hurd.h_i_gid_high（Hurd），或ext2_inode.osd2.linux.l_i_uid_high和ext2_inode.osd2.linux.l_i_gid_high（Linux）。
4.2. 擴展屬性
擴展屬性（Extended Attribute）的定義：文件與目錄偶合的永遠關聯的一組值，類似於與一個進程相關聯的環境信息串。一個屬性可以已定義或沒定義。定義了的屬性其值可以是空的或非空的。
擴展屬性是對標準屬性（Standard Attribute）的擴展，且是與在系統里所有的inode相關聯的。它們常常用於為一個文件系統增加額外的功能——如：使用擴展屬性為文件系統添加類似於訪問控制列表（ACLs）的安全特性。
擴展屬性是作為原子對象被訪問的。讀取時需檢索一個屬性的整個值並將它保存在緩衝區里。寫入時用新的值取代任何一個舊值。
在每一個Ext2 inode里，有一個i_file_acl欄位，它是為訪問控制列表保留的。此欄位的值指出存貯有一個inode擴展屬性的塊的塊號。
擴展屬性被保存於一個「無格式」的磁碟塊，這些塊不隸屬於任何文件，其磁碟布局類似於目錄的布局。在屬性塊頭部後面為入口頭部。入口頭部的大小隨屬性名稱的長度而變。
屬性值和它們的屬性入口描述位於同一個塊，且排列在屬性塊的末尾。這樣有利於添加額外的屬性。
與一個文件關聯的屬性名稱列表可以被檢索。文件系統返回一個屬性名稱的字元串，各名稱之間用1個NULL字元分隔，以2個NULL字元結束列表。
4.2.1. 屬性塊頭部
Figure 4-1. ext2_xattr_header 結構
offset size description
------- ------- -----------
0 4 h_magic
4 4 h_refcount
8 4 h_blocks
12 4 h_hash
16 16 保留
4.2.1.1. h_magic
32bit的Magic標識碼（EXT2_XATTR_MAGIC = 0xEA020000）。
4.2.1.2. h_refcount
32bit值用於計數參考。此值在每次屬性建立一個連接時增加而取消一個連接時減少。當值為0時此屬性塊的空間就可以釋放出開。
4.2.1.3. h_blocks
32bit值表示目前有多少塊用於擴展屬性。
4.2.1.4. h_hash
所有屬性的32bit Hash值。
4.2.2. 屬性入口頭部
Figure 4-2. ext2_xattr_header 結構
offset size description
------- ------- -----------
0 1 e_name_len
1 1 e_name_index
2 2 e_value_offs
4 4 e_value_block
8 4 e_value_size
12 4 e_hash
16 ... e_name
一個屬性入口的大小，它總是包括4-bytes的邊界。
4.2.2.1. e_name_len
8bit無符號值用於表示名稱的長度。
4.2.2.2. e_name_index
8bit無符號值用於屬性名稱的索引。
4.2.2.3. e_value_offs
16bit無符號值表示在值塊里距離值的偏移。
4.2.2.4. e_value_block
32bit，存貯值的塊ID。
4.2.2.5. e_value_size
32bit無符號值表示屬性值的長度。
4.2.2.6. e_hash
屬性名稱和值的32bit Hash值。
4.2.2.7. e_name
屬性名稱。
4.3. 行為控制標記
在inode結構里的i_flags值允許指定文件系統處理文件時的行為。下面是已知的定義：
Table 4-1. 行為控制標記
EXT2_SECRM_FL
0x00000001 安全刪除
EXT2_UNRM_FL
0x00000002 用於反刪除的記錄
EXT2_COMPR_FL
0x00000004 壓縮的文件
EXT2_SYNC_FL
0x00000008 同步更新
EXT2_IMMUTABLE_FL
0x00000010 不可變文件
EXT2_APPEND_FL
0x00000020 只添加
EXT2_NODUMP_FL
0x00000040 不可 Dump/刪除
EXT2_NOATIME_FL
0x00000080 不更新 .i_atime
EXT2_DIRTY_FL
0x00000100 髒的(文件正在使用?)
EXT2_COMPRBLK_FL
0x00000200 壓縮的塊
EXT2_NOCOMPR_FL
0x00000400 Raw方式訪問壓縮的數據
EXT2_ECOMPR_FL
0x00000800 壓縮錯誤
EXT2_BTREE_FL
0x00010000 B-Tree 格式目錄
EXT2_INDEX_FL
0x00010000 Hash 索引的目錄
EXT2_IMAGIC_FL
0x00020000 ?
EXT3_JOURNAL_DATA_FL
0x00040000 日誌文件數據
EXT2_RESERVED_FL
0x80000000 保留
4.3.1. EXT2_SECRM_FL ? 安全刪除
啟用這個位在塊沒有釋放前將引起大小為文件數倍的任意數據被寫入文件。注意：此功能高度依賴實現，且並非100%安全。在使用此功能前請詳細了解當前的實現
4.3.2. EXT2_UNRM_FL ?反刪除的記錄
當實現支持此功能且設置了此位時，被刪除的數據將被除移到一個臨時位置，使用戶恢復原始文件時沒有任何數據丟失的風險。這對於在桌面與工作站使用Ext2來說非常有用。
4.3.3. EXT2_COMPR_FL ? 壓縮的文件
文件的內容被壓縮。所使用的演算法並沒有指出，或許使用超級塊結構里s_algo_bitmap欄位描述的演算法。
4.3.4. EXT2_SYNC_FL ? 同步更新
文件在磁碟里的內容和在內存里的將保持同步一致。像對引導或密鑰等這些會在一次crash里丟失的文件的保護十分有用。
4.3.5. EXT2_IMMUTABLE_FL ? 不可變文件
與此關聯的文件的塊將不會被更換。如在文件系統的整理程序運行時，這些文件將不會被移動。大多用於stage2和stage1.5的引導程序。
4.3.6. EXT2_APPEND_FL ? 只添加
所有的寫入只能將內容添加於文件的末尾而不能更改當前的內容。如郵箱，任何人發送信息給一個用戶時不能更改已有的內容。
4.3.7. EXT2_NODUMP_FL ? 不可Dump/刪除
設置此位可以保護文件不被刪除。只要設置了此位就算i_links_count值為0，文件也不會被刪除。
4.3.8. EXT2_NOATIME_FL ? 不更新 .i_atime
設置此位后當文件被訪問時其inode結構里的i_atime欄位將不被更改。這樣做我能想到的唯一好處便是出於安全性。
4.3.9. EXT2_DIRTY_FL ? 髒的
目前對此沒有更多的信息。
4.3.10. EXT2_COMPRBLK_FL ? 壓縮的塊
如果有一個或更多的塊被壓縮了就設置此位。關於在Ext2的壓縮的更多信息可以訪問http://www.netspace.net.au/~reiter/e2compr/ 但這個項目在1999年就沒有更新了。
4.3.11. EXT2_NOCOMPR_FL ?Raw方式訪問壓縮數據
設置此位后，文件系統實現在將壓縮數據傳送給應用程序時對數據不進行解壓縮。
4.3.12. EXT2_ECOMPR_FL ? 壓縮錯誤
如果在對文件進行解壓縮時檢測出錯誤將設置此位。
4.3.13. EXT2_BTREE_FL - B-Tree Format Directory
4.3.14. EXT2_INDEX_FL - Hash Indexed Directory
若此位被設置，目錄文件的格式是Hash索引的。在Section 2.3有更多的細節。
4.3.15. EXT2_IMAGIC_FL -
4.3.16. EXT2_JOURNAL_DATA_FL ? 日誌文件數據
4.3.17. EXT2_RESERVED_FL - Reserved
Appendix A. 鳴謝
（予原樣保留）
I would like to personally thank everybody who contributed to this document, you are numerous and in many cases I haven't kept track of all of you. Be sure that if you are not in this list, it's a mistake and do not hesitate to contact me, it will be a pleasure to add your name to the list.
Andreas Gruenbacher (a.gruenbacher@bestbits.at)
Section 4.2
Daniel Phillips (phillips@innominate.de)
Section 2.3.1
Section 2.3.2
Section 2.3.3
Section 2.3.4
Section 2.3.5
Section 2.3.6
Section 2.3.7
Jeremy Stanley of Access Data Inc.
Pointed out the inversed values for EXT2_S_IFSOCK and EXT2_S_IFLNK
Appendix B.譯者後記
本譯文原想儘可能按原意完整的給予譯出，希望那些對Ext2文件系統及數據恢復感興趣但又煩於讀E文的朋友們有所幫助。但限於本人的英語水平和對Ext2文件系統及其實現相關知識的局限，譯出來的文字難免錯漏百出。特別是索引目錄相關章節，對這幾節的翻譯大多是生搬硬套的且有3節未能完全譯出。在此特向各位對這方面知識了解的諸位請教，可以通過Email和我聯繫，使我能儘快完善本譯文。謝謝！
