From: Luis Chamberlain <mcgrof@kernel.org>
To: brauner@kernel.org, akpm@linux-foundation.org, hare@suse.de,
willy@infradead.org, dave@stgolabs.net, david@fromorbit.com,
djwong@kernel.org, kbusch@kernel.org
Cc: john.g.garry@oracle.com, hch@lst.de, ritesh.list@gmail.com,
linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, linux-block@vger.kernel.org,
gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com,
kernel@pankajraghav.com, mcgrof@kernel.org
Subject: [PATCH v3 0/8] enable bs > ps for block devices
Date: Fri, 21 Feb 2025 14:38:15 -0800 [thread overview]
Message-ID: <20250221223823.1680616-1-mcgrof@kernel.org> (raw)
Christian, Andrew,
This v3 series addresses the feedback from the v2 series [0]. The only
patch which was mofified was the patch titled "fs/mpage: use blocks_per_folio
instead of blocks_per_page". The motivation for this series is to mainly
start supporting block devices with logical block sizes larger than 4k,
we do this by addressing buffer-head support required for the block
device cache.
In the future these changes can be leveraged to also start experimenting
with LBS support for filesystems which support only buffer-heads. This
paves the way for that work.
Its perhaps is surprising to some but since this also lifts the block
device cache sector size support to 64k, devices which support up to
64k sector sizes can also leverage this to enable filesystems created with
larger sector sizes up to 64k sector sizes. The filesystem sector size
is used or documented in a bit of obscurity except for few filesystems,
but in short it ensures that the filesystem itself will not generate
writes iteslef smaller than the specified sector size. In practice this
means you can constrain metadata writes as well to a minimum size, and
so be completely deterministic with regards to the specified sector size
for min IO writes. For example since XFS can supports up to 32k sector size,
it means with these changes enable filesystems to also be created on x86_64
with both the filesystem block size and sector size to 32k, now that the block
device cache limitation is lifted.
Since this touches buffer-heads I've ran this through fstests on ext4
and found no new regressions. I've also used blktests against a kernel
built with these changes to test block devices with different larger logical
block sizes than 4k on x86_64. All changes to be able to test block
devices with a logical block size support > 4k are now merged on
upstream blktests. I've tested the block layer with blktests with block
devices with logical block sizes up to 64k which is the max we are
currently supporting and found no new regressions.
Detailed changes in this series:
- Modifies the commit log for "fs/buffer: remove batching from async
read" as per Willy's request and collects his SOB.
- Collects Reviewed-by tags
- The patch titled "fs/mpage: use blocks_per_folio instead of blocks_per_page"
received more love to account for Willy's point
that we should keep accounting in order for nr_pages on mpage. This
does this by using folio_nr_pages() on the args passed and adjusts
the last_block accounting accordingly.
- Through code inspection fixed folio_zero_segment() use to use
folio_size() as we move to suppor large folios for unmapped
folio segments on do_mpage_readpage(), this is dealt with on the
patch titled "fs/mpage: use blocks_per_folio instead of blocks_per_page"
as that's when we start accounting large folios into the picture.
[0] https://lkml.kernel.org/r/20250204231209.429356-1-mcgrof@kernel.org
Hannes Reinecke (2):
fs/mpage: avoid negative shift for large blocksize
block/bdev: enable large folio support for large logical block sizes
Luis Chamberlain (5):
fs/buffer: simplify block_read_full_folio() with bh_offset()
fs/mpage: use blocks_per_folio instead of blocks_per_page
fs/buffer fs/mpage: remove large folio restriction
block/bdev: lift block size restrictions to 64k
bdev: use bdev_io_min() for statx block size
Matthew Wilcox (1):
fs/buffer: remove batching from async read
block/bdev.c | 11 ++++----
fs/buffer.c | 58 +++++++++++++++++-------------------------
fs/mpage.c | 49 +++++++++++++++++------------------
include/linux/blkdev.h | 8 +++++-
4 files changed, 59 insertions(+), 67 deletions(-)
--
2.47.2
next reply other threads:[~2025-02-21 22:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 22:38 Luis Chamberlain [this message]
2025-02-21 22:38 ` [PATCH v3 1/8] fs/buffer: simplify block_read_full_folio() with bh_offset() Luis Chamberlain
2025-02-21 22:38 ` [PATCH v3 2/8] fs/buffer: remove batching from async read Luis Chamberlain
2025-02-21 22:38 ` [PATCH v3 3/8] fs/mpage: avoid negative shift for large blocksize Luis Chamberlain
2025-02-21 22:38 ` [PATCH v3 4/8] fs/mpage: use blocks_per_folio instead of blocks_per_page Luis Chamberlain
2025-02-24 7:44 ` Hannes Reinecke
2025-02-21 22:38 ` [PATCH v3 5/8] fs/buffer fs/mpage: remove large folio restriction Luis Chamberlain
2025-02-21 22:38 ` [PATCH v3 6/8] block/bdev: enable large folio support for large logical block sizes Luis Chamberlain
2025-02-21 22:38 ` [PATCH v3 7/8] block/bdev: lift block size restrictions to 64k Luis Chamberlain
2025-02-21 22:38 ` [PATCH v3 8/8] bdev: use bdev_io_min() for statx block size Luis Chamberlain
2025-02-24 10:45 ` [PATCH v3 0/8] enable bs > ps for block devices Christian Brauner
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=20250221223823.1680616-1-mcgrof@kernel.org \
--to=mcgrof@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=da.gomez@samsung.com \
--cc=dave@stgolabs.net \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=kernel@pankajraghav.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=p.raghav@samsung.com \
--cc=ritesh.list@gmail.com \
--cc=willy@infradead.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