EXT2文件系统

ext2 文件系统格式
The Second Extended File System(ext2)文件系统是 Linux 系统中的标准 文件系统，是通过对 Minix 的文件系统进行扩展而得到的，其存取文件的性能 极好。 在 ext2 文件系统中，文件由 inode（包含有文件的所有信息）进行唯一标识。 一个文件可能对应多个文件名，只有在所有文件名都被删除后，该文件才会被 删除。此外，同一文件在磁盘中存放和被打开时所对应的 inode 是不同的，并 由内核负责同步。ext2 文件系统采用三级间接块来存储数据块指针，并以块 （block，默认为 1KB）为单位分配空间。其磁盘分配策略是尽可能将逻辑相 邻的文件分配到磁盘上物理相邻的块中， 并尽可能将碎片分配给尽量少的文件， 以从全局上提高性能。ext2 文件系统将同一目录下的文件（包括目录）尽可能 的放在同一个块组中，但目录则分布在各个块组中以实现负载均衡。在扩展文 件时，会尽量一次性扩展 8 个连续块给文件（以预留空间的形式实现）。
2.1. 总体存储布局 请点评
我们知道，一个磁盘可以划分成多个分区，每个分区必须先用格式化工具（例 如某种 mkfs 命令）格式化成某种格式的文件系统，然后才能存储文件，格式 化的过程会在磁盘上写一些管理存储布局的信息。 下图是一个磁盘分区格式化 成 ext2 文件系统后的存储布局。 图 1. ext2 文件系统的总体存储布局
文件系统中存储的最小单位是块（Block），一个块究竟多大是在格式化时确 定的，例如 mke2fs 的-b 选项可以设定块大小为 1024、2048 或 4096 字节。 而上图中启动块（Boot Block）的大小是确定的，就是 1KB，启动块是由 PC 标准规定的，用来存储磁盘分区信息和启动信息，任何文件系统都不能使用启 动块。 启动块之后才是 ext2 文件系统的开始， ext2 文件系统将整个分区划成若干 个同样大小的块组（Block Group），每个块组都由以下部分组成。

超级块（Super Block） 描述整个分区的文件系统信息，例如块大小、文件系统版本号、上次 mount 的时间等等。 超级块位于每个块组的最前面，每个块组包含超级块的内容是相同的(超级块 在每个块组的开头都有一份拷贝);系统运行期间，把超级块复制到系统缓冲区内， 只需把块组 0 的超级块读入内存，其它块组的超级块做为备份。

超级块的起始位置为其所在分区的第 1024 个字节，占用 1KB 的空间，其结构如下： struct ext2_super_block { __le32 s_inodes_count; // 文件系统中 inode 的总数 __le32 s_blocks_count; // 文件系统中块的总数 __le32 s_r_blocks_count; // 保留块的总数 __le32 s_free_blocks_count; // 未使用的块的总数（包括保留块） __le32 s_free_inodes_count; // 未使用的 inode 的总数 __le32 s_first_data_block; // 块 ID，在小于 1KB 的文件系统中为 0，大于 1KB 的文 件系统中为 1 __le32 s_log_block_size; // 用以计算块的大小（1024 算术左移该值即为块大小） __le32 s_log_frag_size; // 用以计算段大小（为正则 1024 算术左移该值，否则右移） __le32 s_blocks_per_group; // 每个块组中块的总数 __le32 s_frags_per_group; // 每个块组中段的总数 __le32 s_inodes_per_group; // 每个块组中 inode 的总数 __le32 s_mtime; // POSIX 中定义的文件系统装载时间 __le32 s_wtime; // POSIX 中定义的文件系统最近被写入的时间 __le16 s_mnt_count; // 最近一次完整校验后被装载的次数 __le16 s_max_mnt_count; // 在进行完整校验前还能被装载的次数 __le16 s_magic; // 文件系统标志，ext2 中为 0xEF53 __le16 s_state; // 文件系统的状态 __le16 s_errors; // 文件系统发生错误时驱动程序应该执行的操作 __le16 s_minor_rev_level; // 局部修订级别 __le32 s_lastcheck; // POSIX 中定义的文件系统最近一次检查的时间 __le32 s_checkinterval; // POSIX 中定义的文件系统最近检查的最大时间间隔 __le32 s_creator_os; // 生成该文件系统的操作系统 __le32 s_rev_level; // 修订级别 __le16 s_def_resuid; // 报留块的默认用户 ID __le16 s_def_resgid; // 保留块的默认组 ID // 仅用于使用动态 inode 大小的修订版（EXT2_DYNAMIC_REV） __le32 s_first_ino; // 标准文件的第一个可用 inode 的索引（非动态为 11） __le16 s_inode_size; // inode 结构的大小（非动态为 128） __le16 s_block_group_nr; // 保存此超级块的块组号 __le32 s_feature_compat; // 兼容特性掩码 __le32 s_feature_incompat; // 不兼容特性掩码 __le32 s_feature_ro_compat; // 只读特性掩码 __u8 s_uuid[16]; // 卷 ID，应尽可能使每个文件系统的格式唯一 char s_volume_name[16]; // 卷名（只能为 ISO-Latin-1 字符集，以'\0'结束） char s_last_mounted[64]; // 最近被安装的目录 __le32 s_algorithm_usage_bitmap; // 文件系统采用的压缩算法 // 仅在 EXT2_COMPAT_PREALLOC 标志被设置时有效 __u8 s_prealloc_blocks; // 预分配的块数 __u8 s_prealloc_dir_blocks; // 给目录预分配的块数 __u16 s_padding1;

// 仅在 EXT3_FEATURE_COMPAT_HAS_JOURNAL 标志被设置时有效，用以支持日志 __u8 s_journal_uuid[16]; // 日志超级块的卷 ID __u32 s_journal_inum; // 日志文件的 inode 数目 __u32 s_journal_dev; // 日志文件的设备数 __u32 s_last_orphan; // 要删除的 inode 列表的起始位置 __u32 s_hash_seed[4]; // HTREE 散列种子 __u8 s_def_hash_version; // 默认使用的散列函数 __u8 s_reserved_char_pad; __u16 s_reserved_word_pad; __le32 s_default_mount_opts; __le32 s_first_meta_bg; // 块组的第一个元块 __u32 s_reserved[190]; };
块组描述符表（GDT，Group Descriptor Table） 由很多块组描述符组成，整个分区分成多少个块组就对应有多少个块组描述 符。每个块组描述符（Group Descriptor）存储一个块组的描述信息，例如在这 个块组中从哪里开始是 inode 表，从哪里开始是数据块，空闲的 inode 和数据块 还有多少个等等。 和超级块类似，块组描述符表在每个块组的开头也都有一份拷 贝，这些信息是非常重要的，一旦超级块意外损坏就会丢失整个分区的数据，一 旦块组描述符意外损坏就会丢失整个块组的数据，因此它们都有多份拷贝。通常 内核只用到第 0 个块组中的拷贝，当执行 e2fsck 检查文件系统一致性时，第 0 个块组中的超级块和块组描述符表就会拷贝到其它块组， 这样当第 0 个块组的开 头意外损坏时就可以用其它拷贝来恢复，从而减少损失。

存放于超级块所在块的下一个块中。一个块组描述符的结构如下：
struct ext2_group_desc { __le32 bg_block_bitmap; // 块位图所在的第一个块的块 ID __le32 bg_inode_bitmap; // inode 位图所在的第一个块的块 ID __le32 bg_inode_table; // inode 表所在的第一个块的块 ID __le16 bg_free_blocks_count; // 块组中未使用的块数 __le16 bg_free_inodes_count; // 块组中未使用的 inode 数 __le16 bg_used_dirs_count; // 块组分配的目录的 inode 数 __le16 bg_pad; __le32 bg_reserved[3]; };
块位图（Block Bitmap） 一个块组中的块是这样利用的：数据块存储所有文件的数据，比如某个分区 的块大小是 1024 字节，某个文件是 2049 字节，那么就需要三个数据块来存， 即使第三个块只存了一个字节也需要占用一个整块；超级块、块组描述符表、块 位图、inode 位图、inode 表这几部分存储该块组的描述信息。那么如何知道哪 些块已经用来存储文件数据或其它描述信息， 哪些块仍然空闲可用呢？块位图就 是用来描述整个块组中哪些块已用哪些块空闲的，它本身占一个块，其中的每个 bit 代表本块组中的一个块，这个 bit 为 1 表示该块已用，这个 bit 为 0 表示该块 空闲可用。 为什么用 df 命令统计整个磁盘的已用空间非常快呢？因为只需要查看每个 块组的块位图即可，而不需要搜遍整个分区。相反，用 du 命令查看一个较大目 录的已用空间就非常慢，因为不可避免地要搜遍整个目录的所有文件。 与此相联系的另一个问题是：在格式化一个分区时究竟会划出多少个块组呢？ 主要的限制在于块位图本身必须只占一个块。用 mke2fs 格式化时默认块大小是 1024 字节，可以用-b 参数指定块大小，现在设块大小指定为 b 字节，那么一个 块可以有 8b 个 bit，这样大小的一个块位图就可以表示 8b 个块的占用情况，因 此一个块组最多可以有 8b 个块，如果整个分区有 s 个块，那么就可以有 s/(8b) 个块组。格式化时可以用-g 参数指定一个块组有多少个块，但是通常不需要手 动指定，mke2fs 工具会计算出最优的数值。 inode 位图（inode Bitmap） 和块位图类似，本身占一个块，其中每个 bit 表示一个 inode 是否空闲可用。 inode 表（inode Table） 我们知道，一个文件除了数据需要存储之外，一些描述信息也需要存储，例 如文件类型（常规、目录、符号链接等），权限，文件大小，创建/修改/访问时

间等， 也就是 ls -l 命令看到的那些信息， 这些信息存在 inode 中而不是数据块中。 每个文件都有一个 inode，一个块组中的所有 inode 组成了 inode 表。 inode 表占多少个块在格式化时就要决定并写入块组描述符中，mke2fs 格式 化工具的默认策略是一个块组有多少个 8KB 就分配多少个 inode（每个 inode 占用多少字节？128 字节）。由于数据块占了整个块组的绝大部分，也可以近似 认为数据块有多少个 8KB 就分配多少个 inode， 换句话说， 如果平均每个文件的 大小是 8KB， 当分区存满的时候 inode 表会得到比较充分的利用， 数据块也不浪 费。 如果这个分区存的都是很大的文件 （比如电影） 则数据块用完的时候 inode ， 会有一些浪费，如果这个分区存的都是很小的文件（比如源代码），则有可能数 据块还没用完 inode 就已经用完了，数据块可能有很大的浪费。如果用户在格式 化时能够对这个分区以后要存储的文件大小做一个预测，也可以用 mke2fs 的-i 参数手动指定每多少个字节分配一个 inode。
inode 表用于跟踪定位每个文件， 包括位置、 大小等 （但不包括文件名， 文件名包含于 dentry 结构中） ，一个块组只有一个 inode 表。一个 inode 的结构如下： struct ext2_inode { __le16 i_mode; // 文件格式和访问权限 __le16 i_uid; // 文件所有者 ID 的低 16 位 __le32 i_size; // 文件字节数 __le32 i_atime; // 文件上次被访问的时间 __le32 i_ctime; // 文件创建时间 __le32 i_mtime; // 文件被修改的时间 __le32 i_dtime; // 文件被删除的时间（如果存在则为 0） __le16 i_gid; // 文件所有组 ID 的低 16 位 __le16 i_links_count; // 此 inode 被连接的次数 __le32 i_blocks; // 文件已使用和保留的总块数（以 512B 为单位） __le32 i_flags; // 此 inode 访问数据时 ext2 的实现方式 union { struct { __le32 l_i_reserved1; // 保留 } linux1; struct { __le32 h_i_translator; // “翻译者”标签 } hurd1; struct { __le32 m_i_reserved1; // 保留 } masix1; } osd1; // 操作系统相关数据 __le32 i_block[EXT2_N_BLOCKS]; // 定位存储文件的块的数组，前 12 个为块号，第 13 个为一级间接块号，第 14 个为二级间接块号，第 15 个为三级间接块号 __le32 i_generation; // 用于 NFS 的文件版本 __le32 i_file_acl; // 包含扩展属性的块号，老版本中为 0 __le32 i_dir_acl; // 表示文件的“High Size”，老版本中为 0 __le32 i_faddr; // 文件最后一个段的地址

union { struct { __u8 l_i_frag; // 段号 __u8 l_i_fsize; // 段大小 __u16 i_pad1; __le16 l_i_uid_high; // 文件所有者 ID 的高 16 位 __le16 l_i_gid_high; // 文件所有组 ID 的高 16 位 __u32 l_i_reserved2; } linux2; struct { __u8 h_i_frag; // 段号 __u8 h_i_fsize; // 段大小 __le16 h_i_mode_high; __le16 h_i_uid_high; // 文件所有者 ID 的高 16 位 __le16 h_i_gid_high; // 文件所有组 ID 的高 16 位 __le32 h_i_author; } hurd2; struct { __u8 m_i_frag; // 段号 __u8 m_i_fsize; // 段大小 __u16 m_pad1; __u32 m_i_reserved2[2]; } masix2; } osd2; // 操作系统相关数据 };
inode 结构： inode 是 EXT2 基本构件，表示文件系统树型结构的节点。 EXT2 文件系统中的每个文件由一个 inode 描述，且只能由一个 inode 描述。 inode 与文件一起存放在外存，系统运行时，把 inode 写入内存建立映像，加

快文件系统速度。
数据块（Data Block） 根据不同的文件类型有以下几种情况
? ?
? ?
对于常规文件，文件的数据存储在数据块中。 对于目录，该目录下的所有文件名和目录名存储在数据块中，注意文件名保 存在它所在目录的数据块中，除文件名之外，ls -l 命令看到的其它信息都保 存在该文件的 inode 中。注意这个概念：目录也是一种文件，是一种特殊类 型的文件。 对于符号链接， 如果目标路径名较短则直接保存在 inode 中以便更快地查找， 如果目标路径名较长则分配一个数据块来保存。 设备文件、FIFO 和 socket 等特殊文件没有数据块，设备文件的主设备号和 次设备号保存在 inode 中。
现在做几个小实验来理解这些概念。例如在 home 目录下 ls -l：

$ ls -l total 32 drwxr-xr-x 2008-10-25 drwxr-xr-x 2008-10-25 drwx-----2008-07-04
114 akaedu akaedu 12288 11:33 akaedu 114 ftp ftp 4096 10:30 ftp 2 root root 16384 05:58 lost+found
为什么各目录的大小都是 4096 的整数倍？因为这个分区的块大小是 4096，目 录的大小总是数据块的整数倍。 为什么有的目录大有的目录小？因为目录的数据 块保存着它下边所有文件和目录的名字，如果一个目录中的文件很多，一个块装 不下这么多文件名，就可能分配更多的数据块给这个目录。再比如：
$ ls -l /dev ... prw-r----- 1 syslog adm 2008-10-25 11:39 xconsole crw-rw-rw- 1 root root 2008-10-24 16:44 zero
0 1, 5
xconsole 文件的类型是 p（表示 pipe），是一个 FIFO 文件，后面会讲到它其实 是一块内核缓冲区的标识，不在磁盘上保存数据，因此没有数据块，文件大小是 0。zero 文件的类型是 c，表示字符设备文件，它代表内核中的一个设备驱动程 序，也没有数据块，原本应该写文件大小的地方写了 1, 5 这两个数字，表示主 设备号和次设备号，访问该文件时，内核根据设备号找到相应的驱动程序。再比 如：
$ touch hello $ ln -s ./hello halo $ ls -l total 0 lrwxrwxrwx 1 akaedu akaedu 7 2008-10-25 15:04 halo -> ./hello -rw-r--r-- 1 akaedu akaedu 0 2008-10-25 15:04 hello
文件 hello 是刚创建的，字节数为 0，符号链接文件 halo 指向 hello，字节数却 是 7，为什么呢？其实 7 就是“./hello”这 7 个字符，符号链接文件就保存着这 样一个路径名。再试试硬链接：
$ ln ./hello hello2

$ ls -l total 0 lrwxrwxrwx 1 akaedu akaedu 7 2008-10-25 15:04 halo -> ./hello -rw-r--r-- 2 akaedu akaedu 0 2008-10-25 15:04 hello -rw-r--r-- 2 akaedu akaedu 0 2008-10-25 15:04 hello2
hello2 和 hello 除了文件名不一样之外，别的属性都一模一样，并且 hello 的 属性发生了变化，第二栏的数字原本是 1，现在变成 2 了。从根本上说，hello 和 hello2 是同一个文件在文件系统中的两个名字，ls -l 第二栏的数字是硬链 接数， 表示一个文件在文件系统中有几个名字（这些名字可以保存在不同目录的 数据块中，或者说可以位于不同的路径下），硬链接数也保存在 inode 中。既然 是同一个文件， inode 当然只有一个， 所以用 ls -l 看它们的属性是一模一样的， 因为都是从这个 inode 里读出来的。再研究一下目录的硬链接数：
$ mkdir a $ mkdir a/b $ ls -ld a drwxr-xr-x 3 akaedu akaedu 4096 2008-10-25 16:15 a $ ls -la a total 20 drwxr-xr-x 3 akaedu akaedu 4096 2008-10-25 16:15 . drwxr-xr-x 115 akaedu akaedu 12288 2008-10-25 16:14 .. drwxr-xr-x 2 akaedu akaedu 4096 2008-10-25 16:15 b $ ls -la a/b total 8 drwxr-xr-x 2 akaedu akaedu 4096 2008-10-25 16:15 . drwxr-xr-x 3 akaedu akaedu 4096 2008-10-25 16:15 ..
首先创建目录 a，然后在它下面创建子目录 a/b。目录 a 的硬链接数是 3，这 3 个名字分别是当前目录下的 a， 目录下的.和 b 目录下的..。目录 b 的硬链接数 a 是 2，这两个名字分别是 a 目录下的 b 和 b 目录下的.。注意，目录的硬链接只 能这种方式创建，用 ln 命令可以创建目录的符号链接，但不能创建目录的硬链 接。

2.2. 实例剖析 请点评
如果要格式化一个分区来研究文件系统格式则必须有一个空闲的磁盘分区， 为了 方便实验， 我们把一个文件当作分区来格式化，然后分析这个文件中的数据来印 证上面所讲的要点。首先创建一个 1MB 的文件并清零：
$ dd if=/dev/zero of=fs count=256 bs=4K
我们知道 cp 命令可以把一个文件拷贝成另一个文件， dd 命令可以把一个文件 而 的一部分拷贝成另一个文件。这个命令的作用是把/dev/zero 文件开头的 1M （256×4K）字节拷贝成文件名为 fs 的文件。刚才我们看到/dev/zero 是一个 特殊的设备文件，它没有磁盘数据块，对它进行读操作传给设备号为 1, 5 的驱 动程序。/dev/zero 这个文件可以看作是无穷大的，不管从哪里开始读，读出来 的都是字节 0x00。因此这个命令拷贝了 1M 个 0x00 到 fs 文件。if 和 of 参数 表示输入文件和输出文件， count 和 bs 参数表示拷贝多少次， 每次拷多少字节。 做好之后对文件 fs 进行格式化，也就是把这个文件的数据块合起来看成一个 1MB 的磁盘分区，在这个分区上再划分出块组。
$ mke2fs fs mke2fs 1.40.2 (12-Jul-2007) fs is not a block special device. Proceed anyway? (y,n) （输入 y 回车） Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 128 inodes, 1024 blocks 51 blocks (4.98%) reserved for the super user First data block=1 Maximum filesystem blocks=1048576 1 block group 8192 blocks per group, 8192 fragments per group 128 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 27 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.
格式化一个真正的分区应该指定块设备文件名，例如/dev/sda1，而这个 fs 是常 规文件而不是块设备文件， mke2fs 认为用户有可能是误操作了， 所以给出提示， 要求确认是否真的要格式化，输入 y 回车完成格式化。 现在 fs 的大小仍然是 1MB，但不再是全 0 了，其中已经有了块组和描述信息。 用 dumpe2fs 工具可以查看这个分区的超级块和块组描述符表中的信息：
$ dumpe2fs fs dumpe2fs 1.40.2 (12-Jul-2007) Filesystem volume name: Last mounted on: Filesystem UUID: 8e1f3b7a-4d1f-41dc-8928-526e43b2fd74 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: resize_inode dir_index filetype sparse_super Filesystem flags: signed directory hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 128 Block count: 1024 Reserved block count: 51 Free blocks: 986 Free inodes: 117 First block: 1 Block size: 1024 Fragment size: 1024 Reserved GDT blocks: 3 Blocks per group: 8192 Fragments per group: 8192 Inodes per group: 128 Inode blocks per group: 16 Filesystem created: Sun Dec 16 14:56:59 2007 Last mount time: n/a

Last write time: Sun Dec 16 14:56:59 2007 Mount count: 0 Maximum mount count: 30 Last checked: Sun Dec 16 14:56:59 2007 Check interval: 15552000 (6 months) Next check after: Fri Jun 13 14:56:59 2008 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Default directory hash: tea Directory Hash Seed: 6d0e58bd-b9db-41ae-92b3-4563a02a5981
Group 0: (Blocks 1-1023) Primary superblock at 1, Group descriptors at 2-2 Reserved GDT blocks at 3-5 Block bitmap at 6 (+5), Inode bitmap at 7 (+6) Inode table at 8-23 (+7) 986 free blocks, 117 free inodes, 2 directories Free blocks: 38-1023 Free inodes: 12-128 128 inodes per group, 8 inodes per block, so: 16 blocks for inode table
根据上面讲过的知识简单计算一下， 块大小是 1024 字节， 1MB 的分区共有 1024 个块， 0 个块是启动块， 第 启动块之后才算 ext2 文件系统的开始， 因此 Group 0 占据第 1 个到第 1023 个块， 1023 个块。 共 块位图占一个块， 共有 1024×8=8192 个 bit，足够表示这 1023 个块了，因此只要一个块组就够了。默认是每 8KB 分 配一个 inode，因此 1MB 的分区对应 128 个 inode，这些数据都和 dumpe2fs 的 输出吻合。 用常规文件制作而成的文件系统也可以像磁盘分区一样 mount 到某个目录， 例如：

$ sudo mount -o loop fs /mnt $ cd /mnt/ $ ls -la total 17 drwxr-xr-x 3 akaedu akaedu 1024 2008-10-25 12:20 . drwxr-xr-x 21 root 2008-08-18 08:54 .. root 4096
drwx------ 2 root root 12288 2008-10-25 12:20 lost+found
-o loop 选项告诉 mount 这是一个常规文件而不是一个块设备文件。mount 会把 它的数据块中的数据当作分区格式来解释。 文件系统格式化之后在根目录下自动 生成三个子目录：.，..和 lost+found。其它子目录下的.表示当前目录，..表 示上一级目录， 而根目录的.和..都表示根目录本身。lost+found 目录由 e2fsck 工具使用，如果在检查磁盘时发现错误，就把有错误的块挂在这个目录下，因为 这些块不知道是谁的，找不到主，就放在这里“失物招领”了。 现在可以在/mnt 目录下添加删除文件，这些操作会自动保存到文件 fs 中。然后 把这个分区 umount 下来，以确保所有的改动都保存到文件中了。
$ sudo umount /mnt
注意， 下面的实验步骤是对新创建的文件系统做的，如果你在文件系统中添加删 除过文件， 跟着做下面的步骤时结果可能和我写的不太一样， 不过也不影响理解。 现在我们用二进制查看工具查看这个文件系统的所有字节，并且同 dumpe2fs 工 具的输出信息相比较，就可以很好地理解文件系统的存储布局了。
$ od -tx1 000000 00 * 000400 80 000410 75 ... -Ax fs 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 33 00 00 00 da 03 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
其中以*开头的行表示这一段数据全是零因此省略了。 下面详细分析 od 输出的信 息。

从 000000 开始的 1KB 是启动块，由于这不是一个真正的磁盘分区，启动块的 内容全部为零。 000400 到 0007ff 的 1KB 是超级块，对照着 dumpe2fs 的输出 从 信息，详细分析如下： 图 29.3. 超级块
超级块中从 0004d0 到末尾的 204 个字节是填充字节，保留未用，上图未画出。 注意，ext2 文件系统中各字段都是按小端存储的，如果把字节在文件中的位置 看作地址，那么靠近文件开头的是低地址，存低字节。各字段的位置、长度和含 义详见[ULK]。 从 000800 开始是块组描述符表，这个文件系统较小，只有一个块组描述符，对 照着 dumpe2fs 的输出信息分析如下：
... Group 0: (Blocks 1-1023) Primary superblock at 1, Group descriptors at 2-2 Reserved GDT blocks at 3-5

Block bitmap at 6 (+5), Inode bitmap at 7 (+6) Inode table at 8-23 (+7) 986 free blocks, 117 free inodes, 2 directories Free blocks: 38-1023 Free inodes: 12-128 ...
图 29.4. 块组描述符
整个文件系统是 1MB， 每个块是 1KB， 应该有 1024 个块， 除去启动块还有 1023 个块，分别编号为 1-1023，它们全都属于 Group 0。其中，Block 1 是超级块， 接下来的块组描述符指出，块位图是 Block 6，因此中间的 Block 2-5 是块组描 述符表，其中 Block 3-5 保留未用。块组描述符还指出，inode 位图是 Block 7， inode 表是从 Block 8 开始的，那么 inode 表到哪个块结束呢？由于超级块中指 出每个块组有 128 个 inode， 每个 inode 的大小是 128 字节， 因此共占 16 个块， inode 表的范围是 Block 8-23。 从 Block 24 开始就是数据块了。块组描述符中指出，空闲的数据块有 986 个， 由于文件系统是新创建的， 空闲块是连续的 Block 38-1023， 用掉了前面的 Block 24-37。 从块位图中可以看出， 37 位 前 （前 4 个字节加最后一个字节的低 5 位） 都是 1，就表示 Block 1-37 已用:
001800 001810 * 001870 001880 * ff ff ff ff 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
在块位图中，Block 38-1023 对应的位都是 0（一直到 001870 那一行最后一个 字节的低 7 位），接下来的位已经超出了文件系统的空间，不管是 0 还是 1 都 没有意义。可见，块位图每个字节中的位应该按从低位到高位的顺序来看。以后 随着文件系统的使用和添加删除文件，块位图中的 1 就变得不连续了。

块组描述符指出，空闲的 inode 有 117 个，由于文件系统是新创建的，空闲的 inode 也是连续的，inode 编号从 1 到 128，空闲的 inode 编号从 12 到 128。从 inode 位图可以看出，前 11 位都是 1，表示前 11 个 inode 已用：
001c00 ff 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001c10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff *
以后随着文件系统的使用和添加删除文件，inode 位图中的 1 就变得不连续了。 001c00 这一行的 128 位就表示了所有 inode，因此下面的行不管是 0 还是 1 都 没有意义。已用的 11 个 inode 中，前 10 个 inode 是被 ext2 文件系统保留的， 其中第 2 个 inode 是根目录， 11 个 inode 是 lost+found 目录， 第 块组描述符也 指出该组有两个目录，就是根目录和 lost+found。 探索文件系统还有一个很有用的工具 debugfs，它提供一个命令行界面，可以对 文件系统做各种操作，例如查看信息、恢复数据、修正文件系统中的错误。下面 用 debugfs 打开 fs 文件，然后在提示符下输入 help 看看它都能做哪些事情：
$ debugfs fs debugfs 1.40.2 (12-Jul-2007) debugfs: help
在 debugfs 的提示符下输入 stat /命令，这时在新的一屏中显示根目录的 inode 信息：
Inode: 2 Type: directory Mode: 0755 Flags: 0x0 Generation: 0 User: 1000 Group: 1000 Size: 1024 File ACL: 0 Directory ACL: 0 Links: 3 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x4764cc3b -- Sun Dec 16 14:56:59 2007 atime: 0x4764cc3b -- Sun Dec 16 14:56:59 2007 mtime: 0x4764cc3b -- Sun Dec 16 14:56:59 2007 BLOCKS: (0):24 TOTAL: 1
按 q 退出这一屏，然后用 quit 命令退出 debugfs：

debugfs: quit
把以上信息和 od 命令的输出对照起来分析： 图 29.5. 根目录的 inode
上图中的 st_mode 以八进制表示， 包含了文件类型和文件权限， 最高位的 4 表示 文件类型为目录（各种文件类型的编码详见 stat(2)），低位的 755 表示权限。 Size 是 1024，说明根目录现在只有一个数据块。Links 为 3 表示根目录有三个 硬链接，分别是根目录下的.和..，以及 lost+found 子目录下的..。注意，虽然 我们通常用/表示根目录， 但是并没有名为/的硬链接， 事实上， /是路径分隔符， 不能在文件名中出现。这里的 Blockcount 是以 512 字节为一个块来数的，并非 格式化文件系统时所指定的块大小，磁盘的最小读写单位称为扇区（Sector）， 通常是 512 字节，所以 Blockcount 是磁盘的物理块数量，而非分区的逻辑块数 量。根目录数据块的位置由上图中的 Blocks[0]指出，也就是第 24 个块，它在 文件系统中的位置是 24×0x400=0x6000，从 od 命令的输出中找到 006000 地 址，它的格式是这样： 图 29.6. 根目录的数据块

目录的数据块由许多不定长的记录组成，每条记录描述该目录下的一个文件，在 上图中用框表示。第一条记录描述 inode 号为 2 的文件，也就是根目录本身，该 记录的总长度为 12 字节， 其中文件名的长度为 1 字节， 文件类型为 2 （见下表， 注意此处的文件类型编码和 st_mode 不一致），文件名是.。 表 29.1. 目录中的文件类型编码 编码 0 1 2 3 4 5 6 7 文件类型 Unknown Regular file Directory Character device Block device Named pipe Socket Symbolic link
第二条记录也是描述 inode 号为 2 的文件 （根目录） 该记录总长度为 12 字节， ， 其中文件名的长度为 2 字节，文件类型为 2，文件名字符串是..。第三条记录一 直延续到该数据块的末尾，描述 inode 号为 11 的文件（lost+found 目录），该 记录的总长度为 1000 字节（和前面两条记录加起来是 1024 字节），文件类型 为 2，文件名字符串是 lost+found，后面全是 0 字节。如果要在根目录下创建 新的文件，可以把第三条记录截短，在原来的 0 字节处创建新的记录。如果该目 录下的文件名太多，一个数据块不够用，则会分配新的数据块，块编号会填充到 inode 的 Blocks[1]字段。 debugfs 也提供了 cd、ls 等命令，不需要 mount 就可以查看这个文件系统中的 目录，例如用 ls 查看根目录：
2 (12) . lost+found 2 (12) .. 11 (1000)
列出了 inode 号、记录长度和文件名，这些信息都是从根目录的数据块中读出来 的。
2.3. 数据块寻址 请点评
如果一个文件有多个数据块， 这些数据块很可能不是连续存放的，应该如何寻址 到每个块呢？根据上面的分析，根目录的数据块是通过其 inode 中的索引项

Blocks[0]找到的，事实上，这样的索引项一共有 15 个，从 Blocks[0]到 Blocks[14]，每个索引项占 4 字节。前 12 个索引项都表示块编号，例如上面的 例子中 Blocks[0]字段保存着 24，就表示第 24 个块是该文件的数据块，如果块 大小是 1KB，这样可以表示从 0 字节到 12KB 的文件。如果剩下的三个索引项 Blocks[12]到 Blocks[14]也是这么用的，就只能表示最大 15KB 的文件了，这 是远远不够的，事实上，剩下的三个索引项都是间接索引。 索引项 Blocks[12]所指向的块并非数据块， 而是称为间接寻址块 （Indirect Block） ， 其中存放的都是类似 Blocks[0]这种索引项，再由索引项指向数据块。设块大小 是 b，那么一个间接寻址块中可以存放 b/4 个索引项，指向 b/4 个数据块。所以 如果把 Blocks[0]到 Blocks[12]都用上，最多可以表示 b/4+12 个数据块，对于 块大小是 1K 的情况，最大可表示 268K 的文件。如下图所示，注意文件的数据 块编号是从 0 开始的，Blocks[0]指向第 0 个数据块，Blocks[11]指向第 11 个 数据块，Blocks[12]所指向的间接寻址块的第一个索引项指向第 12 个数据块， 依此类推。 图 29.7. 数据块的寻址
从上图可以看出，索引项 Blocks[13]指向两级的间接寻址块，最多可表示 (b/4)2+b/4+12 个数据块，对于 1K 的块大小最大可表示 64.26MB 的文件。索引 项 Blocks[14]指向三级的间接寻址块，最多可表示(b/4)3+(b/4)2+b/4+12 个数据 块，对于 1K 的块大小最大可表示 16.06GB 的文件。 可见，这种寻址方式对于访问不超过 12 个数据块的小文件是非常快的，访问文 件中的任意数据只需要两次读盘操作，一次读 inode（也就是读索引项）一次读 数据块。而访问大文件中的数据则需要最多五次读盘操作：inode、一级间接寻 址块、二级间接寻址块、三级间接寻址块、数据块。实际上，磁盘中的 inode 和 数据块往往已经被内核缓存了，读大文件的效率也不会太低。