ext3文件系统的日志.doc

EXT3文件系统的日志1基本概念和作用12日志的基本原理13日志的三种模式24日志的数据结构44.1概述44.2日志超级块54.3描述块74.4提交块84.5撤消块85实例分析81 基本概念和作用文件系统的一致性：块位图、inode位图、inode指向的数据块、实际的数据块，这些元素要保持一致。向文件中写进新的内容，文件占用了更多的块，块位图更新了，但inode还没有来得及更新，导致一些块被标明已使用，但不知道是哪个文件占用的。作用：日志文件系统在系统崩溃恢复方面更加有效率，只是简单的扫描日志文件并重做那些未完成的文件操作，就可以把文件系统恢复至一致的状态。2 日志的基本原理Ext3 文件系统本身不处理日志，而是利用日志块设备层（Journaling Block Device Layer）或叫JBD 的通用内核层提供的API。JBD致力于提供各种块设备上的日志实现，目前仅有Ext3文件系统使用它来管理日志，Ext3通过调用JBD的API来实现日志功能。举例来说，Ext3代码会将它正在执行的修改操作通知给JBD，在修改磁盘上特定数据之前要取得JBD的许可。作为对Ext3驱动所做操作的回应，JBD会在适当的时候来管理日志。Ext3 与JDB 之间的交互本质上基于三个基本单元：日志记录，原子操作和事务。日志记录本质上是文件系统将要发出的低级操作的描述。在某些日志文件系统中，日志记录只包括操作所修改的字节范围及字节在文件系统中的起始位置。然而，JDB 层使用的日志记录由低级操作所修改的整个缓冲区组成。这种方式可能浪费很多日志空间（例如，当低级操作仅仅改变位图的一个位时），但是，它还是相当快的，因为JBD 层直接对缓冲区和缓冲区首部进行操作。修改文件系统的任一系统调用都通常划分为操纵磁盘数据结构的一系列低级操作。如果这些低级操作还没有全部完成系统就意外宕机，就会损坏磁盘数据。为了防止数据损坏，Ext3文件系统必须确保每个系统调用以原子的方式进行处理。原子操作是对磁盘数据结构的一组低级操作，这组低级操作对应一个单独的高级操作。出于效率的原因，JBD 层对日志的处理采用分组的方法，即把属于几个原子操作处理的日志记录分组放在一个单独的事务中。此外，与一个处理相关的所有日志记录都必须包含在同一个事务中。一个事务的所有日志记录都存放在日志的连续块中。JBD层把每个事务作为整体来处理。例如，只有当包含在一个事务的日志记录中的所有数据提交给文件系统时才回收该事务所使用的块，因此日志是循环使用的。如果事务数据已经写进日志之后，但在实际操作之前或期间发生系统错误，那么在下一次装载文件系统时，将会继续执行未作的操作。如果事务数据尚未写进日志就发生系统错误，则数据会丢失，但文件系统会继续保持一致性。3 日志的三种模式在Ext3文件系统中，日志由三种模式：完全、顺序、写回。完全：将元数据和数据先写进日志，然后在写进相应的磁盘位置。既这种模式需要把数据写进磁盘两次。顺序：先将数据写进磁盘，在把元数据写进日志、再把元数据写进磁盘。写回：把数据写进磁盘、元数据先写进日志，再写进磁盘，但数据和元数据的写入没有固定的先后顺序。这种形式可以保证元数据的一致性，但不能保证数据的一致性。一般情况下，性能最好的是写回，最差的是完全。但在异步随机写时，完全日志的性能会最好。因为写进日志时不需要随机写，而从日志写进文件时，随机写已经被调整成顺序写。写回的性能比顺序稍好一点点。4 日志的数据结构4.1 概述日志作为一个文件出现在文件系统中，默认inode为8，它存放在第一个块组中。日志文件的第一个数据块是日志超级块，后面的块按事务分成组，一个事务包含一组块。一个事务包含以下块：描述块、元数据块、提交块、撤消块。其中，若是FULL DATA日志模式，则元数据块包含元数据块和数据块。日志超级块、描述块、提交块、撤消块包含相同的12字节头部信息表1：日志文件数据块的头部数据结构字节范围含义是否必须03标志(0xC03B3998)是47块类型（见表2）是811事务序列号是表2：日志数据块头部结构中的块类型值含义1描述块2提交块3第一版超级块4第二版超级块5撤消块日志文件的数据全部是大端法表示（平台无关）4.2 日志超级块第一版日志默认操作是记录所有数据的变化，第二版日志仅记录元数据的变化，但通过特殊的mount选项可以强制第二版日志记录全部数据的变化。表3：第1、2版日志超级块共有的数据结构字节范围含义是否必须011标准头（见表1）是1215日志文件块大小是1619日志文件包含的总块数是2023日志的起始块是2427第一个事务的序列号是2831第一个事务的起始块是3235错误编号否版本1的超级块只有上表的36个字节表4：第2版日志超级块特有的数据结构字节范围含义是否必须3639兼容特性否4043不兼容特性否4447只读兼容特性否4863日志的UUID否6467文件系统使用日志的数目否6871超级块副本的保存位置否7275事务占用日志块数的最大值否7679事务占用文件系统块数的最大值否80255未用否2561023文件系统正在使用日志的16字节ID否目前仅使用的一个特性是撤消（revoke）特性，它是不兼容特性，值为0x000000014.3 描述块描述块的前12字节为表1所述的标准头，从第13个字节开始，是一条条的描述项，表5：描述项的数据结构字节范围含义是否必须03文件系统块号是47项标志是823UUID (如果设置了 SAME_UUID ，则没有此项)否描述项中的文件系统块按顺序对应着日志中的元数据块，即描述块后的第一个元数据块对应着第一条描述项中的文件系统块；第二个元数据块对应着第二条描述项中的文件系统块。表6：描述项中的项标志标志值含义0x00后面正常跟有UUID0x01日志块已经被转义（escaped）0x02本条和前一条有同样的UUID（SAME_UUID）0x04本事务已经删除了这个块（目前未使用）0x08描述块中的最后一项转义的含义是：当文件系统块的头四个字节和日志块头相同时，即也是0xC03B3998，为了不引起误会，在将这个数据块写进日志时，清除它的头四个字节，最终将它写进磁盘时在加进去。4.4 提交块提交块只有12字节的标准头，它表示本事务结束。4.5 撤消块撤消块在12字节标准头之后，是一个已取消修改的块列表表7：撤消块的数据结构字节范围含义是否必须011标准头是1215撤消的文件系统块列表的结束位置在本块中的偏移量(offset)是16offset文件系统块地址(4字节)列表是撤消块应用在序列号等于或小于撤消块的序列号的所有事务中。A file system block that was added to the journal can be revoked so that the change is not applied during a recovery. This is done using a revoke block, which contains a sequence number and a list of blocks that were revoked. During recovery, any block that is listed in the revoke block and whose sequence number is less than the sequence number of the revoke block, will not be restored.5 实例分析在/dev/hdb2上创建一个新文件系统# icat -f linux-ext3 /dev/hdb2 8 | xxd0000000: c03b 3998 0000 0004 0000 0000 0000 0400 0000016: 0000 0400 0000 0001 0000 0126 0000 0000 0000032: 0000 0000 0000 0000 0000 0000 0000 0000 0000048: a34c 4be5 c222 460b b76f d45b 518b 083c 0000064: 0000 0001 0000 0000 0000 0000 0000 0000 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 0到3字节是签名，4到7字节显示这个块类型是4，表明它是第二版的超级块。8到11字节显示序列号是0，12到15字节显示日志块大小是1024字节(0x0400)。16到19显示日志由1024个块，20到23显示日志条目开始于日志块1.24到27显示第一个事务的序列号是294 (0x0126),28到31显示这个事务始于块0 。但日志项实际上开始于块1 .这是因为此文件系统是正常卸载的，所有的日志都已提交完毕。挂载这个文件系统，并在它的根目录下创建一个文件new-file.txt，超级块显示如下：# icat -f linux-ext3 /dev/hdb2 8 | xxd0000000: c03b 3998 0000 0004 0000 0000 0000 0400 0000016: 0000 0400 0000 0001 0000 0127 0000 0001 和前一个输出不同的是，序列号已经增加到295 (0x0127)，对应的日志块被设置为块1，这是因为这个事务是有效的、尚未提交的。 现在用jcat看一下日志块1：# jcat -f linux-ext3 /dev/hdb2 1 | xxd0000000: c03b 3998 0000 0001 0000 0127 0000 0004 0000016: 0000 0000 0000 0000 0000 0000 0000 0000 0000032: 0000 0000 0000 0002 0000 0002 0000 000e 0000048: 0000 0002 0000 0005 0000 0002 0000 00a3 0000064: 0000 0002 0000 0003 0000 000a 0000 0000 4到7自己显示这是一个描述块，序列号是295(0x127)。第一个描述项从第12个字节开始，12到15显示是文件系统的块4，16到19是0，表明下面16个字节是UUID。这条目录项表明跟在描述块后面的第一个块对应着文件系统的块4。块4是inode位图，因为是创建文件，需要分配了一个新的inode，所以inode位图块需要更新第二条描述项起始于第36字节，36到39显示是文件系统块2，项标志是2，表明后面没有UUID，即第三条描述项起始于第44字节。块2是文件系统组描述符块；继续解析，块14是inode表所在的块；块5是inode表，其中包含了根目录对应的inode，需要更新它的访问时间；块163是根目录的目录文件数据块；块3是块位图，它后面的标志是0x0a，它表明0x8和0x2同时置位，即它的UUID同前一条描述项，同时它也是最后一条描述项。一共有6条描述项，表明描述块后面有6个元数据块，因此提交块是块8。# jcat -f linux-ext3 /dev/hdb2 8 | xxd0000000: c03b 3998 0000 0002 0000 0127 0000 0000 .;9.0000016: 0000 0000 0000 0000 0000 0000 0000 0000 .字节4到7表明这是一个提交块(0x02)，8到11显示序列号是295(0x127)。日志的块6对应着文件系统块163，是根目录的目录文件，查看一下它# jcat -f linux-ext3 /dev/hdb2 6 | xxd0000000: 0200 0000 0c00 0100 2e00 0000 0200 0000 .0000016: 0c00 0200 2e2e 0000 0b00 0000 e803 0c00 .0000032: 6e65 772d 6669 6c65 2e74 7874 0c00 0000 new-file.txt.REMOVED其中“6e”对应ascii的“n”，65对应e，77对应w用jls可以查看文件系统上的日志文件# jls -f linux-ext3 /dev/hdb2JBlk Descriptrion0: Su