ext3文件系统的日志

1、EXT3文件系统的日志1 基本概念和作用 12日志的基本原理 13日志的三种模式 34日志的数据结构 44.1 概述 44.2 日志超级块 54.3 描述块 74.4 提交块 84.5 撤消块 85 实例分析 81基本概念和作用文件系统的一致性：块位图、inode 位图、inode 指向的数据块、实际的数据块，这些元素要保持一致。向文件中写进新的内容，文件占用了更多的块，块位图更新了，但 inode 还没有来得及更新，导致一些块被标明已使用，但不知道是哪个文件占用的。作用：日志文件系统在系统崩溃恢复方面更加有效率，只是简单的扫描日志文件并重做那些未完成的文件操作，就可以把文件系统恢复至一致的状

2、态。2日志的基本原理Ext3 文件系统本身不处理日志，而是利用日志块设备层(JournalingBlockDeviceLayer)或叫 JBD 的通用内核层提供的 API。JBD 致力于提供各种块设备上的日志实现，目前仅有 Ext3 文件系统使用它来管理日志，Ext3 通过调用 JBD 的 API 来实现日志功能。举例来说， Ext3 代码会将它正在执行的修改操作通知给 JBD,在修改磁盘上特定数据之前要取得 JBD 的许可。作为对 Ext3 驱动所做操作的回应，JBD 会在适当的时候来管理日志。Ext3与 JDB 之间的交互本质上基于三个基本单元：日志记录，原子操作和事务。日志记录本质上是文

3、件系统将要发出的低级操作的描述。在某些日志文件系统中，日志记录只包括操作所修改的字节范围及字节在文件系统中的起始位置。然而，JDB 层使用的日志记录由低级操作所修改的整个缓冲区组成。这种方式可能浪费很多日志空间（例如，当低级操作仅仅改变位图的一个位时），但是，它还是相当快的，因为 JBD 层直接对缓冲区和缓冲区首部进行操作。修改文件系统的任一系统调用都通常划分为操纵磁盘数据结构的一系列低级操作。如果这些低级操作还没有全部完成系统就意外宕机，就会损坏磁盘数据。为了防止数据损坏， Ext3文件系统必须确保每个系统调用以原子的方式进行处理。原子操作是对磁盘数据结构的一组低级操作，这组低级操作对应一个

4、单独的高级操作。出于效率的原因，JBD 层对日志的处理采用分组的方法，即把属于几个原子操作处理的日志记录分组放在一个单独的事务中。止匕外，与一个处理相关的所有日志记录都必须包含在同一个事务中。一个事务的所有日志记录都存放在日志的连续块中。JBD层把每个事务作为整体来处理。例如，只有当包含在一个事务的日志记录中的所有数据提交给文件系统时才回收该事务所使用的块，因此日志是循环使用的。如果事务数据已经写进日志之后，但在实际操作之前或期间发生系统错误，那么在下一次装载文件系统时，将会继续执行未作的操作。如果事务数据尚未写进日志就发生系统错误，则数据会丢失，但文件系统会继续保持一致性。3日志的三种模式在

5、 Ext3 文件系统中，日志由三种模式：完全、顺序、写回。完全：将元数据和数据先写进日志，然后在写进相应的磁盘位置。既这种模式需要把数据写进磁盘两次。顺序：先将数据写进磁盘，在把元数据写进日志、再把元数据写进磁盘。写回：把数据写进磁盘、元数据先写进日志，再写进磁盘，但数据和元数据的写入没有固定的先后顺序。这种形式可以保证元数据的一致性，但不能保证数据的一致性。FullDataOrdered将Inode写进日志3Writeback一般情况下，性能最好的是写回，最差的是完全。但在异步随机写时，完全日志的性能会最好。因为写进日志时不需要随机写，而从日志写进文件时，随机写已经被调整成顺序写。写回的性能

6、比顺序稍好一点点。4日志的数据结构4.1 概述kJ日志作为一个文件出现在文件系统中，默认 inode 为 8,它存放在第一个块组中。日志文件的第一个数据块是日志超级块，后面的块按事务分成组，一个事务包含一组块。一个事务包含以下块：描述块、元数据块、提交块、撤消块。其中，若是 FULLDATA日志模式，则元数据块包含元数据块和数据块。日志超级块、描述块、提交块、撤消块包含相同的 12 字节头部信息表 1:日志文件数据块的头部数据结构数据可在任意时刻写入DescrJtorblockseq1MeiadatablockC&mmitblockseqI0c:哟Metadmscq2bbctMetAc

7、htAMetadatablockblockCommitblockscq2Fixed(Data)将Inode与进日志journal(Inode)1sync日志写入完成,03 标志（0XC03B3998）是47 块类型（见表 2）是811 事务序列号是表 2:日志数据块头部结构中的块类型-描述块提交块第一版超级块第二版超级块撤消块日志文件的数据全部是大端法表示（平台无关）4.2 日志超级块第一版日志默认操作是记录所有数据的变化， 第二版日志仅记录元数据的变化,但通过特殊的 mount 选项可以强制第二版日志记录全部数据的变化。表 3:第 1、2 版日志超级块共有的数据结构011 标准头（见表 1）

8、是1215 日志文件块大小是1619 日志文件包含的总块数是2023 日志的起始块是2427 第一个事务的序列号是2831 第一个事务的起始块是3235 错误编号否版本 1 的超级块只有上表的 36 个字节表 4:第 2 版日志超级块特有的数据结构3639 兼容特性否4043 不兼容特性否4447 只读兼容特性否4863 日志的 UUID 否6467 文件系统使用日志的数目否6871 超级块副本的保存位置否7275 事务占用日志块数的最大否值7679 事务占用文件系统块数的否最大值80255 未用否2561023 文件系统正在使用日志的否16 字节 ID目前仅使用的一个特性是撤消（revoke

9、）特性，它是不兼容特性，值为0 x000000014.3 描述块描述块的前 12 字节为表 1 所述的标准头，从第 13 个字节开始，是一条条的描述项，表 5:描述项的数据结构03 文件系统块号是47 项标志是823UUID（如果设置了 SAME_UUID,则没有此项）否描述项中的文件系统块按顺序对应着日志中的元数据块，即描述块后的第一个元数据块对应着第一条描述项中的文件系统块；第二个元数据块对应着第二条描述项中的文件系统块。表 6:描述项中的项标志0 x00 后面正常跟有 UUID0 x01 日志块已经被转义（escaped0 x02 本条和前一条有同样的 UUID（SAME_UUID）0

10、x04 本事务已经删除了这个块（目前未使用）0 x08 描述块中的最后一项转义的含义是：当文件系统块的头四个字节和日志块头相同时，即也是0XC03B3998,为了不引起误会， 在将这个数据块写进日志时， 清除它的头四个字节， 最终将它写进磁盘时在加进去。4.4 提交块提交块只有 12 字节的标准头，它表示本事务结束4.5 撤消块撤消块在 12 字节标准头之后，是一个已取消修改的块列表表 7:撤消块的数据结构0-11 标准头是1215 撤消的文件系统块列表的结束位置在本是块中的偏移量(offset)16offset 文件系统块地址(4 字节)列表是撤消块应用在序列号等于或小于撤消块的序列号的所有

11、事务中Afilesystemblockthatwasaddedtothejournalcanberevokedsothatthechangeisnotappliedduringarecovery.Thisisdoneusingarevokeblock,whichcontainsasequencenumberandalistofblocksthatwererevoked.Duringrecovery,anyblockthatislistedintherevokeblockandwhosesequencenumberislessthanthesequencenumberoftherevokeblo

12、ck,willnotberestored.5实例分析在/dev/hdb2 上创建一个新文件系统icat-flinux-ext3/dev/hdb28|xxd0000000:c03b39980000000400000000000004000000016:000004000000000100000126000000000000032:000000000000000000000000000000000000048:a34c4be5c222460bb76fd45b518b083c0000064:000000010000000000000000000000000000080:000000000000000

13、000000000000000000 到 3 字节是签名， 4 到 7 字节显示这个块类型是 4,表明它是第二版的超级块 11 字节显示序列号是 0,12 到 15 字节显示日志块大小是 1024 字节(0 x0400)。16 到 19 显示日志由 1024 个块，20 到 23 显示日志条目开始于日志块 1.24 到 27 显示第一个事务的序列号是 294(0 x0126),28到 31 显示这个事务始于块 0。但日志项实际上开始于块 1.这是因为此文件系统是正常卸载的，所有的日志都已提交完毕。挂载这个文件系统，并在它的根目录下创建一个文件 new-file.txt,超级块显示如下：icat

14、-flinux-ext3/dev/hdb28|xxd0000000:c03b39980000000400000000000004000000016:00000400000000010000012700000001和前一个输出不同的是，序列号已经增加到295(0 x0127),对应的日志块被设置为块 1,这是因为这个事务是有效的、尚未提交的。现在用 jcat 看一下日志块 1:jcat-flinux-ext3/dev/hdb21|xxd0000000:c03b39980000000100000127000000040000016:000000000000000000000000000000000

15、000032:0000000000000002000000020000000e0000048:000000020000000500000002000000a30000064:00000002000000030000000a000000004 到 7 自己显示这是一个描述块，序列号是 295(0 x127)。第一个描述项从第 12 个字节开始，12 到 15 显示是文件系统的块 4,16 到 19 是 0,表明下面 16 个字节是 UUIDb 这条目录项表明跟在描述块后面的第一个块对应着文件系统的块 4。块 4 是 inode 位图，因为是创建文件，需要分配了一个新的 inode,所以 inod

16、e 位图块需要更新第二条描述项起始于第 36字节， 36到 39显示是文件系统块 2,项标志是 2,表明后面没有 UUID,即第三条描述项起始于第 44 字节。块 2 是文件系统组描述符块；继续解析，块 14 是 inode 表所在的块；块 5 是 inode 表，其中包含了根目录对应的 inode,需要更新它的访问时间；块 163是根目录的目录文件数据块；块 3 是块位图，它后面的标志是 0 x0a,它表明 0 x8 和 0 x2 同时置位，即它的 UUID 同前一条描述项，同时它也是最后一条描述项。一共有 6 条描述项，表明描述块后面有 6 个元数据块，因此提交块是块 8。jcat-fli

17、nux-ext3/dev/hdb28|xxd0000000:c03b3998000000020000012700000000.;9.0000016:00000000000000000000000000000000字节 4 到 7 表明这是一个提交块(0 x02),8 到 11 显示序列号是 295(0 x127)。日志的块 6 对应着文件系统块 163,是根目录的目录文件，查看一下它jcat-flinux-ext3/dev/hdb26|xxd0000000:020000000c0001002e000000020000000000016:0c0002002e2e00000b000000e8030c000000032:6e65772d66696c652e7478740c000000new-file.txt.REMOVED其中“6e”对应 ascii 的“n”，65 对应 e,77 对应 w”用 jls