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 0/7] btrfs: make subpage handling be feature full
Date: Mon, 24 Feb 2025 10:16:15 +1030	[thread overview]
Message-ID: <cover.1740354271.git.wqu@suse.com> (raw)

[CHANGLOG]
v1:
- Merge previous two patches into one
- Re-order the patches so preparation/fixes are always before feature
  enablement
- Update the commit message of the first patch
  So that we do not focus on the out-of-tree part, but explain why it's
  not ideal in the first place (double page zeroing), and just mention
  the behavior change in the future.

Since the introduction of btrfs subapge support in v5.15, there are
quite some limitations:

- No RAID56 support
  Added in v5.19.

- No memory efficient scrub support
  Added in v6.4.

- No block perfect compressed write support
  Previously btrfs requires the dirty range to be fully page aligned, or
  it will skip compression completely.

  Added in v6.13.

- Various subpage related error handling fixes
  Added in v6.14.

- No support to create inline data extent
- No partial uptodate page support
  This is a long existing optimization supported by EXT4/XFS and
  is required to pass generic/563 with subpage block size.

The last two are addressed in this patchset.

And since all features are implemented for subpage cases, the long
existing experimental warning message can be dropped, as it is already
causing a lot of concerns for users who checks the dmesg carefully.

Qu Wenruo (7):
  btrfs: prevent inline data extents read from touching blocks beyond
    its range
  btrfs: fix the qgroup data free range for inline data extents
  btrfs: introduce a read path dedicated extent lock helper
  btrfs: make btrfs_do_readpage() to do block-by-block read
  btrfs: allow buffered write to avoid full page read if it's block
    aligned
  btrfs: allow inline data extents creation if block size < page size
  btrfs: remove the subpage related warning message

 fs/btrfs/defrag.c       |   2 +-
 fs/btrfs/direct-io.c    |   2 +-
 fs/btrfs/disk-io.c      |   5 -
 fs/btrfs/extent_io.c    | 224 +++++++++++++++++++++++++++++++++++-----
 fs/btrfs/file.c         |   9 +-
 fs/btrfs/inode.c        |  34 +++---
 fs/btrfs/ordered-data.c |  29 ++++--
 fs/btrfs/ordered-data.h |   3 +-
 8 files changed, 239 insertions(+), 69 deletions(-)

-- 
2.48.1


             reply	other threads:[~2025-02-23 23:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-23 23:46 Qu Wenruo [this message]
2025-02-23 23:46 ` [PATCH 1/7] btrfs: prevent inline data extents read from touching blocks beyond its range Qu Wenruo
2025-02-25 15:07   ` Filipe Manana
2025-02-25 16:10     ` Filipe Manana
2025-02-23 23:46 ` [PATCH 2/7] btrfs: fix the qgroup data free range for inline data extents Qu Wenruo
2025-02-25 15:11   ` Filipe Manana
2025-02-23 23:46 ` [PATCH 3/7] btrfs: introduce a read path dedicated extent lock helper Qu Wenruo
2025-02-25 17:05   ` Filipe Manana
2025-02-25 21:12     ` Qu Wenruo
2025-02-25 23:44       ` Qu Wenruo
2025-02-26 11:07         ` Filipe Manana
2025-02-26 11:07       ` Filipe Manana
2025-02-23 23:46 ` [PATCH 4/7] btrfs: make btrfs_do_readpage() to do block-by-block read Qu Wenruo
2025-02-25 17:09   ` Filipe Manana
2025-02-23 23:46 ` [PATCH 5/7] btrfs: allow buffered write to avoid full page read if it's block aligned Qu Wenruo
2025-02-25 17:55   ` Filipe Manana
2025-02-25 21:16     ` Qu Wenruo
2025-02-23 23:46 ` [PATCH 6/7] btrfs: allow inline data extents creation if block size < page size Qu Wenruo
2025-02-25 18:03   ` Filipe Manana
2025-02-23 23:46 ` [PATCH 7/7] btrfs: remove the subpage related warning message Qu Wenruo
2025-02-25 18:10   ` Filipe Manana
2025-02-25 21:19     ` 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.1740354271.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