关于linux下EXT3文件系统的日志是必须的吗
发布网友
发布时间:2022-04-08 09:15
我来回答
共2个回答
懂视网
时间:2022-04-08 13:36
Ext3介绍
对于ext3文件系统,磁盘空间划分一系列block groups,每个group有位图来跟踪inode和data块的分配和范围。其物理布局如下:
Superblock:位于group内第0个block,为了保证兼容,前1024B字节为0,SB从1024B偏移处存储,大小1024B。存储的是文件系统相关信息,在多个group中有备份(0,1,3,5,7,9,25,37,49,81等)。大部分信息在格式化时确定,并只读。可以用dumpe2fs命令查看;
Group Descriptor:位于group内第1个block,描述group信息,如inode bitmap,data blockbitmap等位置信息。group描述符在多个group中有备份。为了保证文件再写入的时候,尽量在一个连续的空间上,ext3文件系统将32768(0x8000)个block组成一个group,group通过Group Descriptor描述,所有的Group Descriptor存在Group Descriptor Table中,整个 desc table 总大小不能超过 1个 block 的大小,对于4096B的block,则最多1024B*4 / 32B = 128个group;
block bitmap:占用1个block,描述block的使用情况;用于group内block的分配;
inode bitmap:占用1个block,描述inode的使用情况;用于group内inode的分配;
inode table:占用多个block,存放inode信息。每个inode 128Byte ,inode是描述数据的数据,即文件系统元数据,是最重要的一部分,包含了文件的权限,拥有者,时间信息,数据存储在哪些 block 上等信息;inode通过多级索引表对block进行管理;inode分配后,会更新到inode bitmap中;
data block:占用多个block,存放数据信息。block分配后,会更新到inode的block索引表和block bitmap中;
JBD介绍
Ext3文件系统作为日志文件系统,其本身不处理日志,而是利用日志块设备(Journaling Block Device)或叫JBD 的通用内核层。JDB有3个核心概念:日志记录,原子操作和事务。
日志记录(journal):本质上是文件系统将要发出的低级操作的描述。在某些日志文件系统中,日志记录只包括操作所修改的字节范围及字节在文件系统中的起始位置。然而,JDB 层使用的日志记录由低级操作所修改的整个缓冲区组成。这种方式可能浪费很多日志空间(例如,当低级操作仅仅改变位图的一个位时),但是,它还是相当快的,因为JBD 层直接对缓冲区和缓冲区首部进行操作。
原子操作(handle):修改文件系统的任一系统调用都通常划分为操纵磁盘数据结构的一系列低级操作。如果这些低级操作还没有全部完成系统就意外宕机,就会损坏磁盘数据。为了防止数据损坏,Ext3文件系统必须确保每个系统调用以原子的方式进行处理。需要原子地完成的一组修改或写操作,叫做原子操作。
事务(transaction):将每个原子操作都写入到日志之中可能不那么高效。为了更高的性能,JBD 将一组原子操作打包为一个事务,并将事务一次写入日志。一个事务的所有日志记录都存放在日志的连续块中。JDB的操作单位是事务。
当事务正在提交时,它的生命周期经历了下面的一系列状态:
- 运行(running):事务当前在内存中,还可以接受新的原子操作。在一个系统中,仅有一个事务可以处于运行状态。
- 锁定(locked):事务不再接受新的原子操作,但现有原子操作们还没有完成。一旦所有原子操作都完成了,事务将进入下一个状态。
- 写入(flush):事务中的所有原子操作都完成了,事务正在写入日志。
- 提交(commit):事务已写入日志。事务会写一个提交块,指示事务log已写入日志。
- 完成(Finished):事务写到日志之后,它会留在那直到所有的块都被更新到磁盘上的实际位置。
Ext3日志模式
Ext3既可以只对元数据做日志,也可以同时对文件数据块做日志。
日志写入分3个阶段:
Journal Write:事务写入到日志空间;
Journal Commit:写入commit块;一个完整commit到日志区的事务以JFS_DESCRIPTOR_BLOCK开始,以JFS_COMMIT_BLOCK结束;
CheckPoint Write:事务写入到磁盘空间,并且其在日志的空间被回收。CheckPointing的触发场景较多,如文件系统缓存达到阈值,日志剩余空间达到阈值,定时器超时等等。
同时,Ext3提供三种日志模式:
Writeback
只有对文件系统元数据的改变才记入日志,也是最快的模式。数据块直接写入磁盘上的真实位置(fixed location),这种模式不保证日志和数据的写入顺序。回写模式是三种模式中一致性最差的,它只保证文件系统元数据的一致性,不保证数据的一致性。
Ordered
只有文件系统元数据才写入日志。但是数据会保证在元数据写入到日志前写入真正存储位置。相比于writeback模式,这种模式提供了更高的一致性保护:数据和元数据都保证一致性。
Journal
文件系统所有数据和元数据的改变都记入日志。这意味着所有数据块会被写2次,一次写入日志,然后再写入磁盘上的真实位置(fixed location)。和ordered一样,data模式提供了相同强度的一致性保护。
日志模式对比分析:
相较于无日志文件系统,日志模式在随机写场景下性能较高;
writeback和ordered在大文件顺序写场景下性能较高;
data将乱序转换为顺序,获取顺序的高性能;所以data在异步小文件随机写场景下性能较高;
data和ordered提供相同的一致性保护;
有些场景下data性能较高,有些场景下ordered性能较高;
ordered模式下,fixed data write, journal inode write,journal commit write依次顺序写入。当日志存于独立的设备上时,这种限制会不必要的降低性能;
大量临时文件的场景下,data和ordered的性能较低,因为定时器刷新元数据到日志时,相应的数据也必须写入,不必要的临时文件写入,增加IO负荷。
Ext3日志视图
日志是管理一个块设备的更新的内部记录(log)。更新首先会放到日志之中,然后再写到它们在磁盘上的真实位置。Ext3的日志(journal)可以看做一个文件,其inode固定为8,位于第一个group中,,其物理布局如下,包含超级块、描述块、提交块等。
Ext3日志的详细内部视图如下,首先是日志的superblock,然后是每个事务描述块,最后是数据块。完整的事务分3部分:事务开始块,数据索引项,事务提交块。
参考文献:
Linux Kernel 2.6.32
Analysis and Evolution of Journaling File Systems
ext3 journaling filesystem (stephen c. tweedie)
journal block device源代码分析
--EOF--
Ext3文件系统及JDB介绍
标签:
热心网友
时间:2022-04-08 10:44
一、简介
日志文件系统就是在传统文件系统的基础上,加入文件系统更改的日志记录,它的设计思想是:跟踪记录文件系统的变化,并将变化内容记录入日志。日志文件系统在磁盘分区中保存有日志记录,写操作首先是对记录文件进行操作,若整个写操作由于某种原因(如系统掉电)而中断,系统重启时,会根据日志记录来恢复中断前的写操作。在日志文件系统中,所有的文件系统的变化都被记录到日志,每隔一定时间,文件系统会将更新后的元数据及文件内容写入磁盘。在对元数据做任何改变以前,文件系统驱动程序会向日志中写入一个条目,这个条目描述了它将要做些什么,然后它修改元数据。
二、Ext3
Ext3文件系统是直接从Ext2文件系统发展而来,目前Ext3文件系统已经非常稳定可靠,它完全兼容Ext2文件系统,用户可以平滑地过渡到一个日志功能健全的文件系统。Ext3日志文件系统的思想就是对文件系统进行的任何高级修改都分两步进行。首先,把待写块的一个副本存放在日志中;其次,当发往日志的I/O 数据传送完成时(即数据提交到日志),块就写入文件系统。当发往文件系统的I/O 数据传送终止时(即数据提交给文件系统),日志中的块副本就被丢弃。
2.1 Ext3日志模式
Ext3既可以只对元数据做日志,也可以同时对文件数据块做日志。具体来说,Ext3提供以下三种日志模式:
日志(Journal )
文件系统所有数据和元数据的改变都记入日志。这种模式减少了丢失每个文件所作修改的机会,但是它需要很多额外的磁盘访问。日志机制面临“写两遍”问题。例如,当一个新文件被创建时,它的所有数据块都必须复制一份作为日志记录。这是最安全和最慢的Ext3日志模式。
写回(Writeback )
只有对文件系统元数据的改变才记入日志,是最快的模式。可以极大减少“写两遍”带来的开销,从而提高写速度,但只能保证元数据一致性。例如,数据尚未写入文件系统而元数据已经写入设备,系统宕机后这部分元数据可以从日志中恢复但是数据已经丢失无法恢复,这就可能造成元数据引用到垃圾数据,因此无法保证文件系统数据一致性。
预定(Ordered )
只有对文件系统元数据的改变才记入日志,但与写回模式不同的是,预定模式严格控制写顺序,即在将元数据写入日志之前必须保证数据已经写入文件系统。这样对于追加写而言,即便写数据中断时元数据尚未写入,由于这部分数据还没有被元数据引用,因此重启后看不到任何垃圾数据。若在写数据过程中断,则直接用元数据日志记录恢复即可。然而,如果是覆盖写,宕机后被覆盖的部分无法恢复,不能保证版本一致性。故预定模式只能保证文件系统数据一致性。这是缺省的Ext3 日志模式。
2.2 日志块设备(JBD)
Ext3文件系统本身不处理日志,而是利用JBD(Journaling Block Device,块设备日志)。Ext3文件系统调用JDB例程以确保在系统万一出现故障时它的后续操作不会损坏磁盘数据结构。Ext3与JDB之间的交互本质上基于三个基本单元:日志记录,原子操作和事务。
Ext3将正在执行的更新操作通知给JBD,JBD接管更新操作涉及的缓冲区(buffer)。这些缓冲区将JBD接管的缓冲区称为日志缓冲区(journal buffer),由JBD在缓冲区头结构(buffer head)之上增加一个日志头结构(journal head)进行管理。所有的日志流程均由JBD控制。
JBD的数据流包含两个部分:写日志和写文件系统。
ps:
文件系统一致性的层次:
1.元数据一致
2.数据一致:不仅要求元数据一致,还要求元数据中引用的数据块必须属于该文件。
3.版本一致:要求元数据中引用的数据块不但属于该文件,还要跟元数据中所标明的版本保持一致。