From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Carlos Maiolino <cem@kernel.org>,
John Garry <john.g.garry@oracle.com>,
"Darrick J. Wong" <djwong@kernel.org>,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH 7/7] xfs: remove the bt_meta_sectorsize field in struct buftarg
Date: Wed, 2 Jul 2025 08:55:06 +1000 [thread overview]
Message-ID: <aGRnSpmkl-C7iMXp@dread.disaster.area> (raw)
In-Reply-To: <20250701104125.1681798-8-hch@lst.de>
On Tue, Jul 01, 2025 at 12:40:41PM +0200, Christoph Hellwig wrote:
> The file system only has a single file system sector size. Read that
This is still an incorrect assertion.
We still have the exact same notion of two different sector sizes
for the data device - one for metadata alignment (from the sb) and
a different one for data (direct IO) alignment (from the bdev).
Removing the abstraction and the comment that explains this does not
make this fundamental data vs metadata sector size difference
within the data device buftarg and betweeen different buftargs
go away.
All you are doing is changing the way this differentiation is
implemented - it's making the data device metadata sector size an
implicit property of *all* buftargs, rather than an explicit
property defined at buftarg instantiation.
IOWs, you are removing an explicit abstraction that exists for
correctness and replacing it with a fixed value that isn't correct
for all buftargs in the filesystem.
> Read that
> from the in-core super block to avoid confusion about the two different
> "sector sizes" stored in the buftarg. Note that this loosens the
> alignment asserts for memory backed buftargs that set the page size here.
I think you got that wrong, because ....
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/xfs/xfs_buf.c | 20 +++++---------------
> fs/xfs/xfs_buf.h | 15 ---------------
> fs/xfs/xfs_buf_mem.c | 2 --
> 3 files changed, 5 insertions(+), 32 deletions(-)
>
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index b73da43f489c..0f20d9514d0d 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -387,17 +387,18 @@ xfs_buf_map_verify(
> struct xfs_buftarg *btp,
> struct xfs_buf_map *map)
> {
> + struct xfs_mount *mp = btp->bt_mount;
> xfs_daddr_t eofs;
>
> /* Check for IOs smaller than the sector size / not sector aligned */
> - ASSERT(!(BBTOB(map->bm_len) < btp->bt_meta_sectorsize));
> - ASSERT(!(BBTOB(map->bm_bn) & (xfs_off_t)btp->bt_meta_sectormask));
> + ASSERT(!(BBTOB(map->bm_len) < mp->m_sb.sb_sectsize));
> + ASSERT(!(BBTOB(map->bm_bn) & (xfs_off_t)(mp->m_sb.sb_sectsize - 1)));
.... these asserts will fire for single block XMBUF buffers because
PAGE_SIZE < mp->m_sb.sb_sectsize when the metadata sector size is
larger than PAGE_SIZE....
Fundamentally, using mp->m_sb.sb_sectsize for all buftargs is simply
wrong. Buftargs have different sector sizes, and we should continue
to encapsulate this in the buftarg.
Also, I can see no obvious reason for getting rid of this
abstraction and none has been given. It doesn't make the code any
cleaner, and it introduces an incorrect implicit assumption in the
buffer cache code (i.e. that every buftarg has the same sector
size). Hence I don't think we actually should be "cleaning up" this
code like this...
Now, if there's some other functional reason for doing this change
that hasn't been stated, let's talk about the change in that
context. Can you explain why this is necessary?
But as a straight cleanup it makes no sense...
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2025-07-01 22:55 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 10:40 misc cleanups v2 Christoph Hellwig
2025-07-01 10:40 ` [PATCH 1/7] xfs: clean up the initial read logic in xfs_readsb Christoph Hellwig
2025-07-01 16:43 ` Darrick J. Wong
2025-07-01 10:40 ` [PATCH 2/7] xfs: remove the call to sync_blockdev in xfs_configure_buftarg Christoph Hellwig
2025-07-01 10:53 ` John Garry
2025-07-01 11:03 ` John Garry
2025-07-03 13:42 ` Christoph Hellwig
2025-07-01 10:40 ` [PATCH 3/7] xfs: add a xfs_group_type_buftarg helper Christoph Hellwig
2025-07-01 11:05 ` John Garry
2025-07-01 16:43 ` Darrick J. Wong
2025-07-01 10:40 ` [PATCH 4/7] xfs: refactor xfs_calc_atomic_write_unit_max Christoph Hellwig
2025-07-01 16:53 ` Darrick J. Wong
2025-07-01 10:40 ` [PATCH 5/7] xfs: rename the bt_bdev_* buftarg fields Christoph Hellwig
2025-07-01 10:54 ` John Garry
2025-07-01 16:45 ` Darrick J. Wong
2025-07-01 10:40 ` [PATCH 6/7] xfs: remove the bt_bdev_file buftarg field Christoph Hellwig
2025-07-01 11:09 ` John Garry
2025-07-01 16:46 ` Darrick J. Wong
2025-07-01 10:40 ` [PATCH 7/7] xfs: remove the bt_meta_sectorsize field in struct buftarg Christoph Hellwig
2025-07-01 16:51 ` Darrick J. Wong
2025-07-01 22:55 ` Dave Chinner [this message]
2025-07-03 13:44 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2025-06-17 10:51 misc cleanups Christoph Hellwig
2025-06-17 10:52 ` [PATCH 7/7] xfs: remove the bt_meta_sectorsize field in struct buftarg Christoph Hellwig
2025-06-17 12:15 ` John Garry
2025-06-17 12:21 ` John Garry
2025-06-18 5:11 ` Christoph Hellwig
2025-06-17 23:51 ` Dave Chinner
2025-06-18 5:15 ` Christoph Hellwig
2025-06-19 2:42 ` Dave Chinner
2025-06-24 14:11 ` Christoph Hellwig
2025-06-24 23:55 ` Dave Chinner
2025-06-25 6:23 ` Christoph Hellwig
2025-06-18 8:09 ` kernel test robot
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=aGRnSpmkl-C7iMXp@dread.disaster.area \
--to=david@fromorbit.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=linux-xfs@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.