All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH RFC 0/9] btrfs: initial bs > ps support
Date: Thu, 18 Sep 2025 08:16:05 +0930	[thread overview]
Message-ID: <cover.1758147788.git.wqu@suse.com> (raw)

This series enables the initial bs > ps support, with several
limitations:

- No direct IO support
  All direct IOs fall back to buffered ones.

- No RAID56 support
  Any fs with RAID56 feature will be rejected at mount time.

- No encoded read/write/send
  Encoded send will fallback to the regular send (reading from page
  cache).
  Encoded read/write utilized by send/receive will fallback to regular
  ones.

Above limits are introduced by the fact that, we require large folios to
cover at least one fs block, so that no block can cross large folio
boundaries.

This simplifies our checksum and RAID56 handling.

The problem is, user space programs can only ensure their memory is
properly aligned in virtual addresses, but have no control on the
physical addresses. Thus they can got a contiguous memory but is backed
by incontiguous pages.

In that case, it will break the "no block can cross large folio
boundaries" assumption, and will need a very complex mechanism to handle
checksum, especially for RAID56.

The same applies to encoded send, which uses vmallocated memory.

In the long run, we will need to support all those complex mechanism
anyway.

- Still some instablity
  Sometimes I can hit the ASSERT()s inside submit_one_sector() where
  we should not get an hole em.

  Still debugging, so far it only occurs on multi-thread fsstress runs.
  Trying to get a smaller reproducer for this bug, but not an easy thing
  so far.

  Maybe memory pressure is involved in this case, as the same seed +
  parameters can not reliably reproduce the ASSERT() reliably.

Qu Wenruo (8):
  btrfs: prepare compression folio alloc/free for bs > ps cases
  btrfs: prepare zstd to support bs > ps cases
  btrfs: prepare lzo to support bs > ps cases
  btrfs: prepare zlib to support bs > ps cases
  btrfs: prepare scrub to support bs > ps cases
  btrfs: fix symbolic link reading when bs > ps
  btrfs: add extra ASSERT()s to catch unaligned bios
  btrfs: enable experimental bs > ps support

 fs/btrfs/bio.c         | 27 +++++++++++++++++++
 fs/btrfs/compression.c | 42 ++++++++++++++++++++---------
 fs/btrfs/compression.h |  2 +-
 fs/btrfs/direct-io.c   | 12 +++++++++
 fs/btrfs/disk-io.c     | 14 ++++++++--
 fs/btrfs/extent_io.c   |  7 +++--
 fs/btrfs/extent_io.h   |  3 ++-
 fs/btrfs/fs.c          | 20 ++++++++++++--
 fs/btrfs/fs.h          |  6 +++++
 fs/btrfs/inode.c       | 18 +++++++------
 fs/btrfs/ioctl.c       | 35 +++++++++++++++++-------
 fs/btrfs/lzo.c         | 59 ++++++++++++++++++++++-------------------
 fs/btrfs/raid56.c      | 43 +++++++++++++++++++++---------
 fs/btrfs/raid56.h      |  4 +--
 fs/btrfs/scrub.c       | 51 +++++++++++++++++++----------------
 fs/btrfs/send.c        |  9 ++++++-
 fs/btrfs/zlib.c        | 60 +++++++++++++++++++++++++++---------------
 fs/btrfs/zstd.c        | 44 +++++++++++++++++--------------
 18 files changed, 313 insertions(+), 143 deletions(-)

-- 
2.50.1


             reply	other threads:[~2025-09-17 22:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-17 22:46 Qu Wenruo [this message]
2025-09-17 22:46 ` [PATCH RFC 1/8] btrfs: prepare compression folio alloc/free for bs > ps cases Qu Wenruo
2025-09-17 22:46 ` [PATCH RFC 2/8] btrfs: prepare zstd to support " Qu Wenruo
2025-09-17 22:46 ` [PATCH RFC 3/8] btrfs: prepare lzo " Qu Wenruo
2025-09-17 22:46 ` [PATCH RFC 4/8] btrfs: prepare zlib " Qu Wenruo
2025-09-17 22:46 ` [PATCH RFC 5/8] btrfs: prepare scrub " Qu Wenruo
2025-09-17 22:46 ` [PATCH RFC 6/8] btrfs: fix symbolic link reading when bs > ps Qu Wenruo
2025-09-17 22:46 ` [PATCH RFC 7/8] btrfs: add extra ASSERT()s to catch unaligned bios Qu Wenruo
2025-09-17 22:46 ` [PATCH RFC 8/8] btrfs: enable experimental bs > ps support 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.1758147788.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.