Ext3 Journal

All filesystem data and metadata changes are logged into the journal. This mode minimizes the chance of losing the updates made to each file, but it requires many additional disk accesses. For example, when a new file is created, all its data blocks must be duplicated as log records. This is the safest and slowest Ext3 journaling mode.

Only changes to filesystem metadata are logged into the journal. However, the Ext3 filesystem groups metadata and relative data blocks so that data blocks are written to disk before the metadata. This way, the chance to have data corruption inside the files is reduced; for instance, each write access that enlarges a file is guaranteed to be fully protected by the journal. This is the default Ext3 journaling mode.

Only changes to filesystem metadata are logged; this is the method found on the other journaling filesystems and is the fastest mode. The journaling mode of the Ext3 filesystem is specified by an option of the mount system command. For instance, to mount an Ext3 filesystem stored in the /dev/sda2 partition on the /jdisk mount point with the "writeback" mode, the system administrator can type the command:

mount -t ext3 -o data=writeback /dev/sda2 /jdisk

1. If the Ext3 filesystem has been mounted in "journal" mode, the commit_write method is implemented by the ext3_journalled_commit_write( ) function, which invokes journal_dirty_metadata( ) on every buffer of data (not metadata) in the page. This way, the buffer is included in the proper dirty list of the active transaction and not in the dirty list of the owner inode; moreover, the corresponding log records are written to the journal. Finally, ext3_journalled_commit_write( ) invokes journal_stop( ) to notify the JBD layer that the atomic operation handle is closed.
2. If the Ext3 filesystem has been mounted in "ordered" mode, the commit_write method is implemented by the ext3_ordered_commit_write( ) function, which invokes the journal_dirty_data( ) function on every buffer of data in the page to insert the buffer in a proper list of the active transactions. The JBD layer ensures that all buffers in this list are written to disk before the metadata buffers of the transaction. No log record is written onto the journal. Next, ext3_ordered_commit_write( ) executes the normal generic_commit_write( ) function described in Chapter 15, which inserts the data buffers in the list of the dirty buffers of the owner inode. Finally, ext3_ordered_commit_write( ) invokes journal_stop( ) to notify the JBD layer that the atomic operation handle is closed.
3. If the Ext3 filesystem has been mounted in "writeback" mode, the commit_write method is implemented by the ext3_writeback_commit_write( ) function, which executes the normal generic_commit_write( ) function described in Chapter 15, which inserts the data buffers in the list of the dirty buffers of the owner inode. Then, ext3_writeback_commit_write( ) invokes journal_stop( ) to notify the JBD layer that the atomic operation handle is closed.
4. commit_write 之后, write 系统调用就结束了

1. kjournald 会定期 commit journal transaction
2. If the Ext3 filesystem has been mounted in "ordered" mode, the journal_commit_transaction( ) function activates the I/O data transfers for all data buffers included in the list of the transaction and waits until all data transfers terminate.
3. The journal_commit_transaction( ) function activates the I/O data transfers for all metadata buffers included in the transaction (and also for all data buffers, if Ext3 was mounted in "journal" mode).
4. Periodically, the kernel activates a checkpoint activity for every complete transaction in the journal. The checkpoint basically involves verifying whether the I/O data transfers triggered by journal_commit_transaction( ) have successfully terminated. If so, the transaction can be deleted from the journal.

真正写磁盘发生在 journal_commit_transaction

journal_commit_transaction:
  // phase 1: write out all data, data first, then metadata, control data
  write_out_data
  // start io
  start_journal_io()
  // phase 2: wait until metadata is written
  wait_for_iobuf
  wait_for_ctlbuf          
  // phase 3: write commit record
  put_bh(bh);     
  // checkpoint

// 生成一个 100 MB 的全 FF 的数据
dd if=/dev/zero ibs=1k count=100000 | tr "\000" "\377" > ~/ff.bin

// 生成 img
dd if=/dev/zero of=test.img bs=1024 count=300000
mkfs.ext3 test.img
mount -o loop test.img -o data=writeback /mnt
sync

// dd
cd /mnt
dd if=~/ff.bin of=./dump.bin

// 等待 8s 后 reset 虚拟机, 因为 ext3 定时 commit journal 的时间默认为 5s,
// 8s 可以保证 metadata 被 commit, 但数据部分可能还没有写入
mount -o loop test.img -o data=writeback /mnt
cd /mnt

// dump.bin 大小与 ff.bin 相同
du -b ./dump.bin

// 但 dump.bin 的内容与 ff 并不一致, od 显示 dump.bin 的开头为 ff, 后面为 0
od -x ./dump.bin

所有步骤与 writeback 相同, 最后的观察结果是:

dump.bin 文件并不存在, 因为 3s 之内数据还没有写完, 导致 metadata 没有 commit