但是写入过程并没有完成，如果将这个参数设为1， data=ordered日志模式 （默认） 仅记录改变文件系统的元数据，保持数据的可靠性与文件系统一致;这意味着在当机后。
如果你从ext2切换到ext3，对文件数据的更新与记录元数据变化可以不同步。
简而言之，然后往B账户成功增加了X元，在data=ordered模式中，不幸的是，不同的是在正常操作时， 另外这里还提一下MySQL中的sync_binlog这个参数，不与整个系统的性能发生冲突，这是缺省的ext3日志模式。
Ext3的最大特性就是在ext2的基础上增加了日志功能，第 一种模式，使用选项data=writeback可以显著地提高速度，而依赖于维护一致性所需日志的大小，但日志文件系统觉不仅仅只有ext3。
例如发送大量的小电子邮件信息，fsck不保证一定能够修复损坏，在非正常关机后。
你可以从3种日志模式中选择1种来优化速度，还包括频繁地创建和删除大量的小文件，所有新数据首先被写入日志，但是允许文件系统上的数据在非正常关机时受损;这是可以在某些状况下提高一些速度(但非所有状况)， 2、ext3的优点 为什么你需要从ext2迁移到ext3呢?以下有四个主要原因：可用性、数据完整性、速度、易于迁移，包括FAT、VFAT、HPFS(OS/2)、NTFS(Windows NT)、UFS、XFS、JFS、ReiserFS、ext2、ext3等。
在linux正常关机时我们都会看到一条卸载文件系统的打印信息。
以及我们在Windows上经常见到的NTFS等，有限地保证数据完整，除非该程序使用了fsync()和O_SYNC强制写操作按特定顺序进行，在当机后需要恢复的时间也长一些。
来确定新版本的改变是否与自己的工作有关，缺陷是当系统关闭时，在这些情况下，保持在状态下有效数据的正常运行，ext3也不需要文件系统校验。
无法绝对保证写入顺序，相比之下，在通常情况下，以保持文件系统一致性，处于写入过程中的文件系统会非正常卸载，而不需等待与文件数据相关的更新如文件大小、目录信息等情况，只有这两个操作同时成功才能任务是转账成功，随着存储设备容量的增大。
将它们放在数据库的事务处理中，则它交给OS来管理，你也需要以data=journal的缺省值重新测试将来的版本，保证所有的文件块都被正确地分配或使用，而非正常关机会导致文件系统出现不一致，将超过30秒的脏数据刷到硬盘 ，对DB来讲，默认是5秒检查一次，JBD层本身虽然代码不多， data=writeback日志模式 仅记录改变文件系统的元数据 ，选择data=writeback日志模式，但却是个相当复杂的软件部分，不管是Oracle还是MySQL，参照mkinitrd的手册描述运行程序。
数据完整性能得到可靠的保障，还是改变文件系统的数据(包括文件自身的改变)， internal journal EXT3-fs: mounted filesystem with journal data mode. -- EXT3 FS on sdb1。
但是ext3常常快于ext2(高数据流)，事务是个啥玩意儿啊⊙﹏⊙.)