From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] mkfs/rootdir: refactor and enhancements, part 1
Date: Mon, 18 May 2026 19:50:56 +0930 [thread overview]
Message-ID: <cover.1779099356.git.wqu@suse.com> (raw)
We have "--reflink" option introduced for mkfs for a while, and recently
the new get_csums ioctl is also introduced, making
add_file_item_extent() much larger and harder to maintain.
I have some concerns about the larger and larger
add_file_item_extent(), and will address some of them in the series:
- Minor mismatches on some parameter/variable names
Use more commonly used names to replace them.
- Duplicated partial block handling
Which not only makes add_file_item_extent() larger but also harder to
read/maintain.
To remove those duplicated partial block handling, the idea is to
shrink the range to block boundary when possible.
If we can not shrink the range anymore, disable reflink/get_csums.
So that we do not need to handle partial blocks for reflink/get_csums.
All the duplicated code can be removed.
- No test case for --reflink nor the latest get_csums option
A new test case, to verify all above mentioned cases.
Qu Wenruo (3):
btrfs-progs: rename logical bytenr parameter for
add_file_item_extent()
btrfs: mkfs/rootdir: refactor the last block handling
btrfs-progs: mkfs-tests: add a new one for '--reflink' option
kernel-shared/extent_io.c | 10 +-
mkfs/rootdir.c | 175 ++++++++-----------
tests/mkfs-tests/043-rootdir-reflink/test.sh | 57 ++++++
3 files changed, 135 insertions(+), 107 deletions(-)
create mode 100755 tests/mkfs-tests/043-rootdir-reflink/test.sh
--
2.54.0
next reply other threads:[~2026-05-18 10:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 10:20 Qu Wenruo [this message]
2026-05-18 10:20 ` [PATCH 1/3] btrfs-progs: rename logical bytenr parameter for add_file_item_extent() Qu Wenruo
2026-05-18 10:20 ` [PATCH 2/3] btrfs: mkfs/rootdir: refactor the last block handling Qu Wenruo
2026-05-18 10:20 ` [PATCH 3/3] btrfs-progs: mkfs-tests: add a new one for '--reflink' option Qu Wenruo
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.1779099356.git.wqu@suse.com \
--to=wqu@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.