关于centos下初识日志式文件系统( 四 )


另外这里还提一下MySQL中的sync_binlog这个参数 。如果将这个参数设为1,也就是说每次写binlog文件将同时刷到硬盘上面去,就 像Oracle的写IO一样 。如果将这个参数关闭,则它交给OS来管理,也就是每5秒检查一次,发现有30秒以前的老数据则刷到硬盘上 。innodb_flush_log_at_trx_commit参数来也涉及到刷硬盘的问题 。
ext3作为ext2的增强版,和ext2使用的superblock、inode、group descriptor等数据结构几乎一模一样,所以ext3前向兼容ext2 。在不用备份ext2文件系统数据的情况下,可以用:
1
# tune2fs –j/dev/sd1
在不用卸载分区的状态下直接将ext2文件系统转换成ext3文件系统 。
假如说,我们在编辑文件时,突然停电了、或系统被锁定被迫得重启,会出现什么后果?轻则文件丢失部分内容,重则整个文件内容混乱,更有甚者文件系统直接崩溃 。这将会是多么可怕的一件事儿 。在linux正常关机时我们都会看到一条卸载文件系统的打印信息,而非正常关机会导致文件系统出现不一致,在系统重新启动阶段挂文件系统时会发现这种不一致,然后它便会尝试去修复它 。不幸的是,随着存储设备容量的增大,这种修复工作所花费的时间越来越无法让人容忍 。
Ext3的最大特性就是在ext2的基础上增加了日志功能,所以ext3文件系统也经常被人们称之为日志文件系统,但日志文件系统觉不仅仅只有ext3,还有诸如JFS、reiserFS和XFS,以及我们在Windows上经常见到的NTFS等 。
Ext3的日志特性主要是依靠其下层一个名为“日志块设备层”的中间设备来完成,叫做JBD(Journaling Block Device layer 简称JBD) 。JBD并不是文件系统规范的一部分,它和ext3文件系统的规范是没有任何的关系的,而JBD正是文件系统事务处理功能的实现基础 。简而言之,JBD 被设计成在任何块设备上实现日志的特殊目的(越说越抽象,事务是个啥玩意儿啊⊙﹏⊙….)
关于事务,有过数据库开发经验或者做数据运维的同学肯定不会陌生 。这里咱不就结概念,也不拘泥学术定义,大家只要知道事务的主要作用就是为了保证操作的原子性。这句话如何理解?比如说,在金融系统中,要从账户A转账X元到账户B 。这一业务必须要确保从A账户成功划出了X元,然后往B账户成功增加了X元 。只有这两个操作同时成功才能任务是转账成功,任何一个操作失败该业务必须终止 。假如从A账户转出X元成功,当往B账户写入时出现了错误,那么从A账户转出的X元必须被退还到A账户 。更极端的情况是,此时A账户所在的数据由于种种原因又崩溃了,那么数据库的事务机制必须保证A账户的X元不会丢失 。这就是数据库业务操作的原子性 。在日志文件系统中这种对文件数据操作的原子性是由JBD来提供保证,Ext3 通过“钩子(hooking in)”JBD的API 来实现其日志记录的功能 。JBD层本身虽然代码不多,但却是个相当复杂的软件部分,这里我们先不鸟它,以后有机会再陪它玩玩儿 。
日志文件系统当然要记录日志,而日志也需要占存储空间 。所以,日志文件系统就是在存储介质上开辟一个块特殊的区域专门用于存储日志信息:

关于centos下初识日志式文件系统


我们利用一幅图来简单描述ext3底层的layout:
关于centos下初识日志式文件系统


推荐阅读