linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* store the buftarg size in the buftarg v2
@ 2025-08-25 11:19 Christoph Hellwig
  2025-08-25 11:19 ` [PATCH 1/2] xfs: track the number of blocks in each buftarg Christoph Hellwig
  2025-08-25 11:19 ` [PATCH 2/2] xfs: use bt_nr_blocks in xfs_dax_translate_range Christoph Hellwig
  0 siblings, 2 replies; 10+ messages in thread
From: Christoph Hellwig @ 2025-08-25 11:19 UTC (permalink / raw)
  To: Carlos Maiolino; +Cc: linux-xfs

Hi all,

when playing around with new code that stores more than the current
superblock in block zero of the RT device I ran into the assert in
xfs_buf_map_verify that checks that a buffer is withing sb_dblocks.

That check is obviously incorrect for targets that are not the main data
device, but unlike to hit in practice as the log buftarg doesn't store
any cached buffers, the RT device currently only one for block 0, and
the in-memory buftargs better don't grow larger than the data device.

It's probably better to fix it anyway before running into real issues
on day, and storing the value also removes the need for the notify
failure code to poke into the block device.

Changes since v1:
 - grow the correct buftarg when applying the growfs deltas

Diffstat:
 xfs_buf.c              |   38 +++++++++++++++++++++-----------------
 xfs_buf.h              |    4 +++-
 xfs_buf_item_recover.c |    7 +++++++
 xfs_notify_failure.c   |    2 +-
 xfs_super.c            |    7 ++++---
 xfs_trans.c            |   21 ++++++++++-----------
 6 files changed, 46 insertions(+), 33 deletions(-)

^ permalink raw reply	[flat|nested] 10+ messages in thread
* store the buftarg size in the buftarg
@ 2025-08-18  5:11 Christoph Hellwig
  2025-08-18  5:11 ` [PATCH 1/2] xfs: track the number of blocks in each buftarg Christoph Hellwig
  0 siblings, 1 reply; 10+ messages in thread
From: Christoph Hellwig @ 2025-08-18  5:11 UTC (permalink / raw)
  To: Carlos Maiolino; +Cc: linux-xfs

Hi all,

when playing around with new code that stores more than the current
superblock in block zero of the RT device I ran into the assert in
xfs_buf_map_verify that checks that a buffer is withing sb_dblocks.

That check is obviously incorrect for targets that are not the main data
device, but unlike to hit in practice as the log buftarg doesn't store
any cached buffers, the RT device currently only one for block 0, and
the in-memory buftargs better don't grow larger than the data device.

It's probably better to fix it anyway before running into real issues
on day, and storing the value also removes the need for the notify
failure code to poke into the block device.

Diffstat:
 xfs_buf.c              |   38 +++++++++++++++++++++-----------------
 xfs_buf.h              |    4 +++-
 xfs_buf_item_recover.c |    7 +++++++
 xfs_notify_failure.c   |    2 +-
 xfs_super.c            |    7 ++++---
 xfs_trans.c            |   21 ++++++++++-----------
 6 files changed, 46 insertions(+), 33 deletions(-)

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2025-08-26 13:29 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-25 11:19 store the buftarg size in the buftarg v2 Christoph Hellwig
2025-08-25 11:19 ` [PATCH 1/2] xfs: track the number of blocks in each buftarg Christoph Hellwig
2025-08-25 15:26   ` Darrick J. Wong
2025-08-26 13:28     ` Christoph Hellwig
2025-08-26  5:42   ` Dave Chinner
2025-08-26 13:29     ` Christoph Hellwig
2025-08-25 11:19 ` [PATCH 2/2] xfs: use bt_nr_blocks in xfs_dax_translate_range Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2025-08-18  5:11 store the buftarg size in the buftarg Christoph Hellwig
2025-08-18  5:11 ` [PATCH 1/2] xfs: track the number of blocks in each buftarg Christoph Hellwig
2025-08-18 20:48   ` Darrick J. Wong
2025-08-19  8:06     ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).