diff options
| author | Filipe Manana <fdmanana@suse.com> | 2016-02-26 02:19:38 +0300 |
|---|---|---|
| committer | Chris Mason <clm@fb.com> | 2016-03-01 19:23:47 +0300 |
| commit | 5e33a2bd7ca7fa687fb0965869196eea6815d1f3 (patch) | |
| tree | 5f90810654e14860bb062f991bc07aee29db3366 /block/blk-exec.c | |
| parent | affc0ff902d539ebe9bba405d330410314f46e9f (diff) | |
| download | linux-5e33a2bd7ca7fa687fb0965869196eea6815d1f3.tar.xz | |
Btrfs: do not collect ordered extents when logging that inode exists
When logging that an inode exists, for example as part of a directory
fsync operation, we were collecting any ordered extents for the inode but
we ended up doing nothing with them except tagging them as processed, by
setting the flag BTRFS_ORDERED_LOGGED on them, which prevented a
subsequent fsync of that inode (using the LOG_INODE_ALL mode) from
collecting and processing them. This created a time window where a second
fsync against the inode, using the fast path, ended up not logging the
checksums for the new extents but it logged the extents since they were
part of the list of modified extents. This happened because the ordered
extents were not collected and checksums were not yet added to the csum
tree - the ordered extents have not gone through btrfs_finish_ordered_io()
yet (which is where we add them to the csum tree by calling
inode.c:add_pending_csums()).
So fix this by not collecting an inode's ordered extents if we are logging
it with the LOG_INODE_EXISTS mode.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'block/blk-exec.c')
0 files changed, 0 insertions, 0 deletions