Ext3 Data=Ordered vs Data=Writeback mode

From Ext4
Revision as of 01:59, 21 July 2009 by Tytso (Talk | contribs)

Jump to: navigation, search

If a filesystem does not explicitly specify a data ordering mode, and the journal capability allowed it, ext3 used to historically default to 'data=ordered'. This become configurable in 2.6.30, when the configuration option CONFIG_EXT3_DEFAULTS_TO_ORDERED was added. If this CONFIG option is disabled, it will change the default to be data=writeback.

Data=ordered mode is the mode used by most distributions, but can introduce latency problems in some workloads, especially if there is a combination of high bandwidth background writes and foreground processes calling fsync() and waiting for the result. In worst case scenarios, the fsync() call can take 500ms to multiple seconds to return.

However, the problem with using a default of data=writeback, is that is that after a system crash or a power failure, files that were written right before the system went down could contain previously written data or other garbage. With data=ordered mode, journal commits are deferred until the data blocks get written to disk. This guarantees that any blocks in the file will be data written by the application, avoiding a possibility of a security breach, which is especially problematic on a multi-user system. (Note, however, that data=ordered does not guarantee that the file will be consistent at an application level; the application must use fsync() at appropriate commit points in order to guarantee application-level consistency.)

In addition, there are some applications which depend on data=ordered to automatically force data blocks to be written to disk soon after the file is written. The data=writeback option extends the time from when a file is written to when it is pushed out to disk to 30 seconds. This can be surprising for some users; however, it should be noted that such problems can still be an issue with data=ordered (although they are much rarer). A careful application or library should always use fsync() at points where the application stable is at a stable commit point.

If you have been historically happy with ext3's performance, data=ordered mode will be a safe choice and you should enable CONFIG_EXT3_DEFAULTS_TO_ORDERED. However, if the latency problems are causing problems for you, and you understand the reliability and data privacy issues of data=writeback, you can disable this option.

Filesystems can be forced to use to use a specific data journalling mode by using specifying a mount option on the command line, or in /etc/fstab, or by using the "tune2fs -o journal_data_ordered" or "tune2fs -o journal_data_writeback" to specify a default mount option in the filesystem superblock.

Personal tools