ext3日志文件系统理解

1.         对于ext3日志文件系统。是一个事务,对应同一个时间戳?

对于ext3Ordered模式(默认模式)来说

事务里面仅包含元数据,包括 inode,bitmap等,这些都会被先写到JBD层所在的磁盘上。每个事务都有自己的状态标记,比如是否committed。没有commit会被放到一起,然后被JBDscan下刷。在没有断电的情况下,是直接把内存中的相应内容刷到磁盘,断电后重启后,把JBD层没有commit的,重新刷到磁盘。形成一个向前回滚的情况。


每个文件操作一般会修改inode(里面有磁盘布局, read_page等ops), super_block(包括一些计数)。 在JDB层,会有相应结构JDB_buffer, 它里面应该有一个指针指向这些内存内容,那些脏的buffer会被放到一个transaction(事务)里面,这些transcaction会被串到一个链上,超时,或者JDB没有空间容纳更多的transcaction时,就需要下刷这些transaction。 

也就是说,ext3元数据的下刷都要通过JDB, 到了JDB以后,transaction到达commit状态, 但是还没有到达 check_point状态。 只有到达check_point状态以后, 才能说明meta data已经从JDB(磁盘)写到相应的实际磁盘位置了。

断电重启后, 检查那些transaction的状态, 若为commit 但还不是check_point,则需要把这些事务重新往磁盘刷一遍。

以上只是JDB的一种思想, 细节不一定正确。


JBD层是在磁盘上的一个固定位置。


2.         Ext3 JDB 之间的交互本质上基于三个基本单元:日志记录,原子操作和事务


3.         出于效率的原因,JBD 层对日志的处理采用分组的方法,即把属于几个原子操作处理的日志记录分组放在一个单独的事务中。此外,与一个处理相关的所有日志记录都必须包含在同一个事务中。一个事务的所有日志记录都存放在日志的连续块中。JBD层把每个事务作为整体来处理。例如,只有当包含在一个事务的日志记录中的所有数据提交给文件系统时才回收该事务所使用的块

你可能感兴趣的:(ext,buffer,磁盘)