From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: linux-btrfs@vger.kernel.org
Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
Subject: [PATCH 0/2] Limit scope of extent locks in btrfs_buffered_write()
Date: Wed, 28 Aug 2024 08:45:48 -0400 [thread overview]
Message-ID: <cover.1724847323.git.rgoldwyn@suse.com> (raw)
From: Goldwyn Rodrigues <rgoldwyn@suse.com>
This is in preparation for using iomap for btrfs. It will help in
keeping the extent lock limited to iomap_end() function.
The extent locks are taken for a majority of the write sequence. With
Josef patches limiting the extent locks to recording extent changes, we
can reduce the scope of locking of extent locks during write to only
when recording the extent as delalloc. Restrict the locking to
btrfs_dirty_pages(). However, the write needs to make sure that there
are no pending ordered extents. So, wait for any pending ordered extents
before performing the copying of data from userspace.
As for testing, it did go through a round of xfstests without any crash
or failure. However, since this touches a crucial part of write, please
make sure this is correct especially in terms of data corruption by
overwrites/staleness.
Goldwyn Rodrigues (2):
btrfs: btrfs_has_ordered_extent() to check for ordered extent in range
btrfs: reduce scope of extent locks during buffered write
fs/btrfs/file.c | 109 ++++++----------------------------------
fs/btrfs/ordered-data.c | 11 ++++
fs/btrfs/ordered-data.h | 1 +
3 files changed, 28 insertions(+), 93 deletions(-)
--
2.46.0
next reply other threads:[~2024-08-28 12:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 12:45 Goldwyn Rodrigues [this message]
2024-08-28 12:45 ` [PATCH 1/2] btrfs: btrfs_has_ordered_extent() to check for ordered extent in range Goldwyn Rodrigues
2024-08-28 13:28 ` Filipe Manana
2024-08-28 12:45 ` [PATCH 2/2] btrfs: reduce scope of extent locks during buffered write Goldwyn Rodrigues
2024-08-28 13:17 ` Filipe Manana
2024-08-28 14:21 ` Filipe Manana
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=cover.1724847323.git.rgoldwyn@suse.com \
--to=rgoldwyn@suse.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=rgoldwyn@suse.com \
/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