Filipe Manana 49dae1bc1c Btrfs: fix fsync data loss after a ranged fsync
While we're doing a full fsync (when the inode has the flag
BTRFS_INODE_NEEDS_FULL_SYNC set) that is ranged too (covers only a
portion of the file), we might have ordered operations that are started
before or while we're logging the inode and that fall outside the fsync
range.

Therefore when a full ranged fsync finishes don't remove every extent
map from the list of modified extent maps - as for some of them, that
fall outside our fsync range, their respective ordered operation hasn't
finished yet, meaning the corresponding file extent item wasn't inserted
into the fs/subvol tree yet and therefore we didn't log it, and we must
let the next fast fsync (one that checks only the modified list) see this
extent map and log a matching file extent item to the log btree and wait
for its ordered operation to finish (if it's still ongoing).

A test case for xfstests follows.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
2014-09-08 13:56:43 -07:00
..
2014-06-09 17:20:42 -07:00
2014-06-09 17:20:48 -07:00
2014-06-09 17:20:48 -07:00
2013-11-11 22:03:19 -05:00
2008-09-25 11:04:06 -04:00
2014-09-08 13:56:42 -07:00
2013-03-14 14:57:10 -04:00
2013-02-01 14:24:23 -05:00
2014-01-29 07:06:27 -08:00