public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v4 0/5] btrfs-progs: mkfs/rootdir: cleanup and test case enhancement
Date: Thu,  9 Apr 2026 18:21:59 +0930	[thread overview]
Message-ID: <cover.1775724568.git.wqu@suse.com> (raw)

[CHANGELOG]
v4:
- Fix a bug that adds the data size twice
  It's in the last patch, when the source fs supports SEEK_DATA,
  ftw_data_size is added twice (by on-disk size and st_size)

v3:
- Remove the fiemap based prealloc detection
  The complexity doesn't really bring any other benefit and preallocated
  space itself is not that commonly used for fs image creation.

- Update the image size estimation
  To fully co-operate with the new hole detection.

v2:
- Add a new test case to verify hole detection with/without no-holes
  There is a bug in the ^no-holes handling that an incorrect file extent
  is inserted with uninitialized type.

  Exposed and fixed by Mark.

- Add a new test case to verify the file contents of hole detection

  There is a bug in the refactor of read, which overwrites the buffer
  instead of properly advance the cursor.

  Exposed by Mark with Chris Mason's review prompts.

- Keep the existing first block based bad compress ratio detection
  Previously if we had bad compression ratio after the first block, we
  do not mark the inode incompressible.

  Follow the existing behavior.

- Fix the hole size capping in fiemap mode
  Which previously is not capping the hole size, and can trigger
  UASSERT()s.

- Enhance the new fiemap test case with fssum
  To verify both the hole and file contents matches.

The PR can be found here:

  https://github.com/kdave/btrfs-progs/pull/1103

The first 2 patches are enhancing mkfs test cases to be more robust,
covering both no-holes and ^no-holes features, as Mark exposed a bug
affecting ^no-holes only in previous hole-detection.

The 3rd patch extracts btrfs_insert_hole_extent() to make it a little
simpler to use, without the need to populate a local on-stack file
extent item.

The 4th patch makes compressed write path easier to read, without
combining both compressed and uncompressed paths.

The final one is to use st_blocks to estimate the data size, so the
resulted fs image can be as small as possible.

Qu Wenruo (5):
  btrfs-progs: mkfs-tests: also test hole-deteciton without no-holes
  btrfs-progs: mkfs-tests: add a test case to verify the content of
    rootdir
  btrfs-progs: implement the missing btrfs_insert_hole_extent()
  btrfs-progs: mkfs/rootdir: extract compressed write path
  btrfs-progs: mkfs/rootdir: use st_blocks for size estimation

 Makefile                                      |   2 +-
 kernel-shared/file-item.c                     |  17 ++
 kernel-shared/file.c                          |   6 +-
 mkfs/rootdir.c                                | 277 ++++++++++--------
 tests/mkfs-tests/041-hole-detection/test.sh   |  48 +--
 tests/mkfs-tests/042-rootdir-contents/test.sh |  57 ++++
 6 files changed, 265 insertions(+), 142 deletions(-)
 create mode 100755 tests/mkfs-tests/042-rootdir-contents/test.sh

--
2.53.0


             reply	other threads:[~2026-04-09  8:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09  8:51 Qu Wenruo [this message]
2026-04-09  8:52 ` [PATCH v4 1/5] btrfs-progs: mkfs-tests: also test hole-deteciton without no-holes Qu Wenruo
2026-04-09  8:52 ` [PATCH v4 2/5] btrfs-progs: mkfs-tests: add a test case to verify the content of rootdir Qu Wenruo
2026-04-09  8:52 ` [PATCH v4 3/5] btrfs-progs: implement the missing btrfs_insert_hole_extent() Qu Wenruo
2026-04-09  8:52 ` [PATCH v4 4/5] btrfs-progs: mkfs/rootdir: extract compressed write path Qu Wenruo
2026-04-09  8:52 ` [PATCH v4 5/5] btrfs-progs: mkfs/rootdir: use st_blocks for size estimation 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.1775724568.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox