数据完整性
在大多数情况下，用户都是在文件的末尾写入数据。仅仅在某些情况下（例如数据库），用户在现存文件的中间写入数据。甚至覆盖现存文件的操作，是通过先截断该文件，然后再从文件末尾写入数据来实现的。在data=ordered模式中，如果正在写文件时系统崩溃，那么数据块可能被部分改写，但是写入过程并没有完成，所以系统存在不属于任何文件的不完整数据块。在data=ordered模式中，崩溃后残存无序数据块的唯一情况是在崩溃过程中一个程序正在重写某个文件。在这种情况下，无法绝对保证写入顺序，除非该程序使用了fsync()和O_SYNC强制写操作按特定顺序进行。
ext3文件系统还涉及到如何cache中的数据刷到硬盘上。它是通过kupdate进程来实现定期刷的，默认是5秒检查一次，将超过30秒的脏数据刷到硬盘。
在as 3.0中可以通过修改/proc/sys/vm/bdflush来达到目的。而在as 4.0中可以通过修改/proc/sys/vm/dirty_writeback_centisecs和/proc/sys/vm/dirty_expire_centisecs来达到目的。
由于默认是ordered模式，在这种模式下面，如果一个IO先写数据文件，然后再写日志文件。假如说在写完数据文件之后，写日志文件之前时，系统发生crashed，则这部分数据将会丢失，这在数据库是绝对不允许的，不管是Oracle还是MySQL。所以对数据库的写来说，每一次写操作都会先写到pagecache中，然后通知kernelthread 将这个buffers刷到硬盘，然后再将元数据写日志，最后才返回写成功的操作。这样对数据库来说写操作是明显不如写祼设备快。
所以说在采用Ext3跑数据库的情况下，将日志模式设为journal模式，性能反而应该会有所提升(没有测试过，理论上分析应该 是这样)。 因为在journal模式下数据库一个写操作，先是直接将数据和文件系统的变化写到日志中(绕开cache直接写，性能较好)，然后将数据写到cache 中，接着由kupdate进程将数据刷新到硬盘上。 相比之下，对DB来讲，它的性能应该比前面一种要快。
另外这里还提一下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正常关机时我们都会看到一条卸载文件系统的打印信息，而非正常关机会导致文件系统出现不一致，在系统重新启动阶段挂文件系统时会发现这种不一致，然后它便会尝试去修复它。不幸的是，随着存储设备容量的增大，这种修复工作所花费的时间越来越无法让人容忍。
