EXT4是一种journaling文件系统，使用了类似于MySQL中Transaction的概念来保证一致性，把对文件的操作看做是一次事务，并且也使用了先写redo log的机制。分为以下三种模式（可以用dmesg | grep EXT4查看：mounted filesystem with ordered data mode. Opts: (null)）

• journal 将数据及元数据都先写入日志文件并落盘，commit日志文件，然后再将数据和元数据写入硬盘正确的位置(In-place write)，异步删除已经写入硬盘正确位置的日志文件数据。如果发生系统crash，可以replay日志文件中已经commit的数据进行恢复。这种模式最安全但性能较差（除了数据需要同时被写入和读取），因为数据被写入了两次。流程如下：

• ordered（默认） 只有元数据写入日志文件，但保证先将数据写入硬盘，再commit日志文件，流程图如下（第1,2步可以同时进行，只要保证在第3步前完成就行）：

“Delayed allocation” means that the filesystem tries to delay the allocation of physical disk blocks for written data for as long as possible. This policy brings some important performance benefits. Many files are short-lived; delayed allocation can keep the system from writing fleeting temporary files to disk at all. And, for longer-lived files, delayed allocation allows the kernel to accumulate more data and to allocate the blocks for data contiguously, speeding up both the write and any subsequent reads of that data. It’s an important optimization which is found in most contemporary filesystems. But, if blocks have not been allocated for a file, there is no need to write them quickly as a security measure. Since the blocks do not yet exist, it is not possible to read somebody else’s data from them. So ext4 will not (cannot) write out unallocated blocks as part of the next journal commit cycle. Those blocks will, instead, wait until the kernel decides to flush them out; at that point, physical blocks will be allocated on disk and the data will be made persistent. The kernel doesn’t like to let file data sit unwritten for too long, but it can still take a minute or so (with the default settings) for that data to be flushed - far longer than the five seconds normally seen with ext3. And that is why a crash can cause the loss of quite a bit more data when ext4 is being used.

• writeback 只有元数据写入日志文件，但不保证数据写入硬盘什么时候发生。有可能系统重启后元数据被恢复，但数据因为并没有写入硬盘而丢失。流程图如下：

 1 /dev/mapper/sd03 /pi/ ext4 defaults,data=journal 0 0 

ext4 and data loss