From: Filipe Manana <fdmanana@xxxxxxxx>
Btrfs doesn't respect the given range for a fsync when the inode's has the
"need full sync" bit set - it treats the fsync as a full ranged one, operating
on the whole file, doing more IO and cpu work then needed.
That behaviour was needed to fix a corruption bug. Commit 0c713cbab6200b
("Btrfs: fix race between ranged fsync and writeback of adjacent ranges")
fixed that bug by turning the ranged fsync into a full one.
Later the hole detection code of fsync was simplified a lot in order to
fix another bug when using the NO_HOLES feature - done by commit
0e56315ca147b3 ("Btrfs: fix missing hole after hole punching and fsync when
using NO_HOLES").
That commit now makes it easy to avoid turning the ranged fsyncs into
non-ranged fsyncs. This patchset does that. The first two patches are
just cleanups to make the fix easier and less verbose.
A special note is that test generic/456 now fails as fsck reports a missing
file extent item due to an implicit hole (when not using the NO_HOLES feature).
This wasn't supposed to happen anymore after Josef's recent patches that
changes how we update the on disk i_size of an inode. That patchset was
supposed to fix all case of missing file extent items for holes, but there's
more cases which I uncovered while working on this. I'm moving the discussion
of those particular cases under the e-mail thread of Josef's patch that has
the subject:
"btrfs: use the file extent tree infrastructure"
That has the following address on lore:
https://lore.kernel.org/linux-btrfs/CAL3q7H69_tEsV2WGu9Y6ZgB_1gy9WKPB5iR9XiWaUGiU6C871A@xxxxxxxxxxxxxx/T/#u
Thanks.
Filipe Manana (3):
Btrfs: add helper to get the end offset of a file extent item
Btrfs: factor out inode items copy loop from btrfs_log_inode()
Btrfs: make ranged full fsyncs more efficient
fs/btrfs/ctree.h | 1 +
fs/btrfs/file-item.c | 40 ++++--
fs/btrfs/file.c | 13 --
fs/btrfs/inode.c | 10 +-
fs/btrfs/send.c | 44 +-----
fs/btrfs/tree-log.c | 379 +++++++++++++++++++++++++++++----------------------
6 files changed, 251 insertions(+), 236 deletions(-)
--
2.11.0
