概述
ext2磁盘布局
任何Ext2分区中的第一个块从不受Ext2文件系统的管理，因为这一块是为分区的引导扇区所保留的。Ext2分区的其余部分被分割成块组（block group），每个块组的分布图如下图1所示。正如你从图中所看到的，一些数据结构正好可以放在一块中，而另一些可能需要更多的块。在Ext2文件系统中的所有块组大小相同并被顺序存放，因此，内核可以从块组的整数索引很容易地得到磁盘中一个块组的位置。
图1 ext2 磁盘布局
由于内核尽可能地把属于同一个文件的数据块存放在同一块组中，所以块组可有效地提高文件连续性。每个块组均包含如下方面的信息：
文件系统超级块的拷贝；
文件系统所有块组描述符；
块组数据块位图；
inode表位图；
inode表；
块组内的数据块。
事实上，只有块组0中所包含超级块和组描述符才由内核使用，而其余的超级块和组描述符都保持不变，内核甚至不考虑它们。当e2fsck程序对Ext2文件系统的状态执行一致性检查时，就引用存放在块组0中的超级块和组描述符，然后将它们拷贝到其他所有的块组中。如果出现数据损坏，并且块组0中的主超级块和主描述符变为无效，那么，系统管理员就可以命令e2fsck引用存放在某个块组（除了第一个块组）中的超级块和组描述符的旧拷贝。通常情况下，这些多余的拷贝所存放的信息足以让e2fsck把Ext2分区带回到一个一致的状态。
那么每个ext2文件系统到底有多少块组呢？这取决于分区的大小和块的大小。其主要限制在于块位图，块位图用来标识一个块组中块的占用和空闲状况，而且ext2块位图只占据一个单独的数据块。所以，每组中至多可包含8×b个块，b是以字节为单位的块大小。例如，一个块大小是 1024 Byte，那么，一个块的位图就有8192个位，正好就对应8192个块。因此，块组的总数大约是c/8×b，这里c是指分区所包含的总块组数。
举例说明，让我们考虑一下32GB的Ext2分区，换算成KB就是33554432，假定块大小为4KB。在这种情况下，每个4KB的块位图描述32KB个数据块，即128MB。因此，最多需要33554432 / 4096 * 32 = 256个块组。显然，块越大，块组数越小。
inode表用于存储块组内文件的inode信息，而且只存储该块组内存储文件的inode，我们知道inode是一个文件元数据的全部，是文件身份的象征，没有inode，文件在磁盘上就是不可见的。ext2文件系统格式化时，块组内的inode表空间也一并分配好，也就意味着该块组内能存储多少个文件是确定的，那么这个值是如何确定的呢，依稀记得mkfs.ext2在格式化时，会将块组存储文件的平均大小设定为16KB，这样，知道了块组大小和文件平均大小就可以计算块组内存储文件数量了。
inode位图用来管理块组内空闲inode分配情况。
数据块用来存储块组内的文件数据，使用位图方式管理空闲数据块。
至此，我们已经大概了解了ext2文件系统的磁盘布局，ext2这种布局方式是源自FFS的设计思想：尽量将文件的数据元数据连续存放，同时尽量将相关文件连续存放，所谓的相关文件诸如相同目录下的所有文件，ext2的块组思想就是连续的最好体现，关于ext2的文件创建和数据块分配后续还会仔细研究。
ext2元数据结构
概述
ext2超级块
1 /*
2 * Structure of the super block
3 */
4 struct ext2_super_block {
5 __le32 s_inodes_count; /* Inodes count 索引节点总数*/
6 __le32 s_blocks_count; /* Blocks count 块大小，即文件系统以块为单位的大小*/
7 __le32 s_r_blocks_count; /* Reserved blocks count */
8 __le32 s_free_blocks_count; /* Free blocks count */
9 __le32 s_free_inodes_count; /* Free inodes count */
10 __le32 s_first_data_block; /* First Data Block */
11 __le32 s_log_block_size; /* Block size */
12 __le32 s_log_frag_size; /* Fragment size */
13 __le32 s_blocks_per_group; /* # Blocks per group 每个块组中的块数*/
14 __le32 s_frags_per_group; /* # Fragments per group */
15 __le32 s_inodes_per_group; /* # Inodes per group 每个块组中的索引节点个数*/
16 __le32 s_mtime; /* Mount time */
17 __le32 s_wtime; /* Write time */
18 __le16 s_mnt_count; /* Mount count */
19 __le16 s_max_mnt_count; /* Maximal mount count */
20 __le16 s_magic; /* Magic signature */
21 __le16 s_state; /* File system state */
22 __le16 s_errors; /* Behaviour when detecting errors */
23 __le16 s_minor_rev_level; /* minor revision level */
24 __le32 s_lastcheck; /* time of last check */
25 __le32 s_checkinterval; /* max. time between checks */
26 __le32 s_creator_os; /* OS */
27 __le32 s_rev_level; /* Revision level */
28 __le16 s_def_resuid; /* Default uid for reserved blocks */
29 __le16 s_def_resgid; /* Default gid for reserved blocks */
30 /*
31 * These fields are for EXT2_DYNAMIC_REV superblocks only.
32 *
33 * Note: the difference between the compatible feature set and
34 * the incompatible feature set is that if there is a bit set
35 * in the incompatible feature set that the kernel doesn't
36 * know about, it should refuse to mount the filesystem.
37 *
38 * e2fsck's requirements are more strict; if it doesn't know
39 * about a feature in either the compatible or incompatible
40 * feature set, it must abort and not try to meddle with
41 * things it doesn't understand...
42 */
43 __le32 s_first_ino; /* First non-reserved inode */
44 __le16 s_inode_size; /* size of inode structure */
45 __le16 s_block_group_nr; /* block group # of this superblock */
46 __le32 s_feature_compat; /* compatible feature set */
47 __le32 s_feature_incompat; /* incompatible feature set */
48 __le32 s_feature_ro_compat; /* readonly-compatible feature set */
49 __u8 s_uuid[16]; /* 128-bit uuid for volume */
50 char s_volume_name[16]; /* volume name */
51 char s_last_mounted[64]; /* directory where last mounted */
52 __le32 s_algorithm_usage_bitmap; /* For compression */
53 /*
54 * Performance hints. Directory preallocation should only
55 * happen if the EXT2_COMPAT_PREALLOC flag is on.
56 */
57 __u8 s_prealloc_blocks; /* Nr of blocks to try to preallocate*/
58 __u8 s_prealloc_dir_blocks; /* Nr to preallocate for dirs */
59 __u16 s_padding1;
60 /*
61 * Journaling support valid if EXT3_FEATURE_COMPAT_HAS_JOURNAL set.
62 */
63 __u8 s_journal_uuid[16]; /* uuid of journal superblock */
64 __u32 s_journal_inum; /* inode number of journal file */
65 __u32 s_journal_dev; /* device number of journal file */
66 __u32 s_last_orphan; /* start of list of inodes to delete */
67 __u32 s_hash_seed[4]; /* HTREE hash seed */
68 __u8 s_def_hash_version; /* Default hash version to use */
69 __u8 s_reserved_char_pad;
70 __u16 s_reserved_word_pad;
71 __le32 s_default_mount_opts;
72 __le32 s_first_meta_bg; /* First metablock block group */
73 __u32 s_reserved[190]; /* Padding to the end of the block */
74 };
可以看到，ext2磁盘超级块结构中大部分是描述整个文件系统的信息，如文件系统中块组的数量，inode数量，磁盘块的数量等等，不一而足，基本上从代码的注释我们就能比较清楚各个成员的含义，而且在后续的文章中我们或多或少地也会遇到这些成员，另外ext2超级块的最后一部分成员是为了兼容ext3而设计的，可能是为了更方便地从ext2升级至ext3吧，当然这只是我的猜测而已。
ext2块组描述符
/*
* Structure of a blocks group descriptor
*/
struct ext2_group_desc
{
__le32 bg_block_bitmap; /* Blocks bitmap block */
__le32 bg_inode_bitmap; /* Inodes bitmap block */
__le32 bg_inode_table; /* Inodes table block */
__le16 bg_free_blocks_count; /* Free blocks count */
__le16 bg_free_inodes_count; /* Free inodes count */
__le16 bg_used_dirs_count; /* Directories count */
__le16 bg_pad;
__le32 bg_reserved[3];
};
ext2文件目录项
struct ext2_dir_entry_2 {
__le32 inode; /* Inode number inode编号 */
__le16 rec_len; /* Directory entry length */
__u8 name_len; /* Name length */
__u8 file_type;
char name[EXT2_NAME_LEN]; /* File name */
};
在该结构中，inode代表该文件inode编号，rec_len表示本文件目录项的大小，为什么需要这个rec_len呢，结构体定义好了整个长度不也就确认了嘛？非也，这是因为该结构体的最后一个成员name并不是固定长度的，其最大可以支持256字节，因此必须要有一个长度域来保存当前目录项长度，name_len指的是文件名长度，既然已经有了rec_len，为什么还需要文件名长呢，岂不多此一举？这是考虑到存在文件名填充的问题。从效率上来考虑，每个struct ext2_dir_entry_2最终都会被填充成4字节整数倍，对于目录项不是4字节整数倍的，需要在最后name文件名后面填充若干个0，因此name_len中记录的便是name[]域中有效文件名长度（即不包含0）。考虑下图所示事例：
1. “.”和“..”文件名后都填充了‘ ’以使文件目录项总长度为4的整数倍；
2. music和src文件/目录均也填充了‘ ’以使文件目录项总长度为4的整数倍;
3. test.txt因为其文件目录项已经是16个字节，无需填充。
ext2索引节点
/*
* Structure of an inode on the disk
*/
struct ext2_inode {
__le16 i_mode; /* File mode */
__le16 i_uid; /* Low 16 bits of Owner Uid */
__le32 i_size; /* Size in bytes */
__le32 i_atime; /* Access time */
__le32 i_ctime; /* Creation time */
__le32 i_mtime; /* Modification time */
__le32 i_dtime; /* Deletion Time */
__le16 i_gid; /* Low 16 bits of Group Id */
__le16 i_links_count; /* Links count */
__le32 i_blocks; /* Blocks count */
__le32 i_flags; /* File flags */
union {
struct {
__le32 l_i_reserved1;
} linux1;
struct {
__le32 h_i_translator;
} hurd1;
struct {
__le32 m_i_reserved1;
} masix1;
} osd1; /* OS dependent 1 */
__le32 i_block[EXT2_N_BLOCKS];/* Pointers to blocks */
__le32 i_generation; /* File version (for NFS) */
__le32 i_file_acl; /* File ACL */
__le32 i_dir_acl; /* Directory ACL */
__le32 i_faddr; /* Fragment address */
union {
struct {
__u8 l_i_frag; /* Fragment number */
__u8 l_i_fsize; /* Fragment size */
__u16 i_pad1;
__le16 l_i_uid_high; /* these 2 fields */
__le16 l_i_gid_high; /* were reserved2[0] */
__u32 l_i_reserved2;
} linux2;
struct {
__u8 h_i_frag; /* Fragment number */
__u8 h_i_fsize; /* Fragment size */
__le16 h_i_mode_high;
__le16 h_i_uid_high;
__le16 h_i_gid_high;
__le32 h_i_author;
} hurd2;
struct {
__u8 m_i_frag; /* Fragment number */
__u8 m_i_fsize; /* Fragment size */
__u16 m_pad1;
__u32 m_i_reserved2[2];
} masix2;
} osd2; /* OS dependent 2 */
};
