ext4 mount option data mode: journal ordered writeback

[root@digoal ~]# cat /proc/10249/stack 
[<ffffffffa009f0ad>] do_get_write_access+0x29d/0x520 [jbd2]
[<ffffffffa009f481>] jbd2_journal_get_write_access+0x31/0x50 [jbd2]
[<ffffffffa00fcb68>] __ext4_journal_get_write_access+0x38/0x80 [ext4]
[<ffffffffa00d02f3>] ext4_reserve_inode_write+0x73/0xa0 [ext4]
[<ffffffffa00d036c>] ext4_mark_inode_dirty+0x4c/0x1d0 [ext4]
[<ffffffffa00d0530>] ext4_dirty_inode+0x40/0x60 [ext4]
[<ffffffff811a18fb>] __mark_inode_dirty+0x3b/0x160
[<ffffffff81191da2>] file_update_time+0xf2/0x170
[<ffffffff81114070>] __generic_file_aio_write+0x210/0x470
[<ffffffff8111433f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa00c9171>] ext4_file_write+0x61/0x1e0 [ext4]
[<ffffffff81177c7a>] do_sync_write+0xfa/0x140
[<ffffffff81177f78>] vfs_write+0xb8/0x1a0
[<ffffffff81178981>] sys_write+0x51/0x90
[<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff

[root@digoal ~]# cat /proc/10255/stack 
[<ffffffffa009f0ad>] do_get_write_access+0x29d/0x520 [jbd2]
[<ffffffffa009f481>] jbd2_journal_get_write_access+0x31/0x50 [jbd2]
[<ffffffffa00fcb68>] __ext4_journal_get_write_access+0x38/0x80 [ext4]
[<ffffffffa00caca5>] ext4_new_inode+0x3d5/0x1260 [ext4]
[<ffffffffa00da603>] ext4_create+0xc3/0x150 [ext4]
[<ffffffff811858c4>] vfs_create+0xb4/0xe0
[<ffffffff811893cf>] do_filp_open+0xb2f/0xd60
[<ffffffff81175599>] do_sys_open+0x69/0x140
[<ffffffff811756b0>] sys_open+0x20/0x30
[<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff

[root@localhost group1]# sysctl -a|grep dirty
vm.dirty_background_ratio = 0
vm.dirty_background_bytes = 1638400
vm.dirty_ratio = 50
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 100
vm.dirty_expire_centisecs = 3000

postgres@localhost-> ps -ewf|grep flush
root      1100     2  0 Aug14 ?        00:03:18 [flush-253:0]
root      1102     2  0 Aug14 ?        00:01:32 [flush-253:2]
root     26851     2  0 10:04 ?        00:00:04 [flush-253:1]
root     50052     2  0 10:40 ?        00:00:00 [flush-8:0]

Data Mode
=========
There are 3 different data modes:

* writeback mode
In data=writeback mode, ext4 does not journal data at all.  This mode provides
a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
mode - metadata journaling.  A crash+recovery can cause incorrect data to
appear in files which were written shortly before the crash.  This mode will
typically provide the best ext4 performance.

* ordered mode
In data=ordered mode, ext4 only officially journals metadata, but it logically
groups metadata information related to data changes with the data blocks into a
single unit called a transaction.  When it's time to write the new metadata
out to disk, the associated data blocks are written first.  In general,
this mode performs slightly slower than writeback but significantly faster than journal mode.

* journal mode
data=journal mode provides full data and metadata journaling.  All new data is
written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state.  This mode is the slowest except when data
needs to be read from and written to disk at the same time where it
outperforms all others modes.  Enabling this mode will disable delayed
allocation and O_DIRECT support.

       O_DSYNC
              Write operations on the file will complete according to the
              requirements of synchronized I/O data integrity completion.

              By the time write(2) (and similar) return, the output data has
              been transferred to the underlying hardware, along with any
              file metadata that would be required to retrieve that data
              (i.e., as though each write(2) was followed by a call to
              fdatasync(2)).  See NOTES below.

DESCRIPTION
       fsync()  transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) where that file resides.  The call
       blocks until the device reports that the transfer has completed.  It also flushes metadata information associated with the file (see stat(2)).

       Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk.  For that an explicit fsync() on a file descriptor for the directory is also needed.

       fdatasync() is similar to fsync(), but does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be correctly handled.  For example, changes to st_atime or  st_mtime  (respectively,
       time  of  last access and time of last modification; see stat(2)) do not require flushing because they are not necessary for a subsequent data read to be handled correctly.  On the other hand, a change to the file size (st_size, as made
       by say ftruncate(2)), would require a metadata flush.

       The aim of fdatasync() is to reduce disk activity for applications that do not require all metadata to be synchronized with the disk.