From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Cc: josef@toxicpanda.com
Subject: [PATCH 0/3] Btrfs: make ranged fsyncs always respect the given range
Date: Fri, 6 Mar 2020 11:53:29 +0000 [thread overview]
Message-ID: <20200306115329.16947-1-fdmanana@kernel.org> (raw)
From: Filipe Manana <fdmanana@suse.com>
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@mail.gmail.com/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
reply other threads:[~2020-03-06 11:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200306115329.16947-1-fdmanana@kernel.org \
--to=fdmanana@kernel.org \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox