diff options
author | Jan Kara <jack@suse.cz> | 2011-05-24 12:00:54 -0400 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2011-05-24 12:00:54 -0400 |
commit | 93628ffb9ba67c154849ac6c387f98f5e3198b84 (patch) | |
tree | 5aeeedb16744a901f945897fda4822e3b852cec5 /fs/omfs | |
parent | bbd2be36910728f485ac78ea36e0f4f5a38e691e (diff) | |
download | linux-3.10-93628ffb9ba67c154849ac6c387f98f5e3198b84.tar.gz linux-3.10-93628ffb9ba67c154849ac6c387f98f5e3198b84.tar.bz2 linux-3.10-93628ffb9ba67c154849ac6c387f98f5e3198b84.zip |
ext4: fix waiting and sending of a barrier in ext4_sync_file()
jbd2_log_start_commit() returns 1 only when we really start a
transaction. But we also need to wait for a transaction when the
commit is already running. Fix this problem by waiting for
transaction commit unconditionally (which is just a quick check if the
transaction is already committed).
Also we have to be more careful with sending of a barrier because when
transaction is being committed in parallel to ext4_sync_file()
running, we cannot be sure that the barrier the journalling code sends
happens after we wrote all the data for fsync (note that not every
data writeout needs to trigger metadata changes thus commit of some
metadata changes can be running while other data is still written
out). So use jbd2_will_send_data_barrier() helper to detect the common
cases when we can be sure barrier will be issued by the commit code
and issue the barrier ourselves in the remaining cases.
Reported-by: Edward Goggin <egoggin@vmware.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to 'fs/omfs')
0 files changed, 0 insertions, 0 deletions