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

[CHANGELOG]
RFC->v1
- Disable extra large folios for bs > ps mounts
  Such extra large folios are larger than a block.

  Still debugging, but disabling it makes 8K block size runs survive the
  full fs tests, with some minor failures due to the limitations.

  This may be something affecting regular large folios (folio > bs,
  but bs <= ps).

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.

- No extra large folios (folio > bs > ps)
  Still debugging the weird out-of-sync dirty and OE creation for extra
  large folios.

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
backing folios. 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.

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     | 20 +++++++++++---
 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      | 42 +++++++++++++++++++----------
 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, 315 insertions(+), 146 deletions(-)

-- 
2.50.1


             reply	other threads:[~2025-09-18 22:58 UTC|newest]

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