update BDI {io,ra}_pages values based on the RT device limits

update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

Hi all,

we ran into a bit of a funny case where adding an SSD to store metadata
to a (zoned) XFS file system reduced the performance vs using a HDD for
both data and metadata.  It turns out this is due to readahead code
looking at the BDI limits, including the io_pages value that can't be
inspected or tuned from userspace.

This patch has the simplest fix for that by just updating the values from
XFS, but for a long-term solution this feels a bit ugly.  Other, a lot
more invasive options would be:


  1) support multiple BDIs per file system.

	This would work pretty well for XFS, as data for a given file is
	always entirely on one device, and the VFS writeback code is not
	used for metadata.  But it probably doesn't work well for other
	cases

  2) stop propagating these values through the BDI

	Have a way to query these parameters from the file system, either
	through a method if we want to be fully dynamic, or through fields
	instead of going through the BDI.  The downside would be that
	sysfs modifications of the readahead size would not work after
	the file system initially queried them.

Thoughts?

[PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

When using XFS with a main device on an SSD that stores metadata and a RT
device to store data on a HDD, we fail to take the I/O sizes for the RT
device into accounting, leading to up to 5% slower read performance when
using an SSD for metadata vs storing data and metadata on the HDD.

Fix this up by taking the RT settings into account.  Note that this
updates the BDI owned by the main device, and leaves those settings in
place even when the file system is unmounted.  This is a bit unexpected
but not different from manual tuning through sysfs (although that is only
possible for the ra_pages value).

Reported-by: Filip Blagojevic <filip.blagojevic@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_super.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index e6781f86d867..88edd3822872 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -546,6 +546,29 @@ xfs_open_devices(
 	return error;
 }
 
+/*
+ * When using a RT device some or all data I/O is using the RT device, but
+ * the BDI is inherited from the main data device.  When the underlying block
+ * device for the RT device has larger I/O sizes, the BDI settings might be
+ * incorrect, which is especially bad if the main device is a SSD and the
+ * RT device is a HDD, as the io_opt fixup in blk_apply_bdi_limits is missing
+ * for this case.
+ *
+ * Update the BDI values to the max of the data and RT device to cover our
+ * bases.
+ */
+static void
+xfs_update_bdi_rahead(
+	struct xfs_mount	*mp)
+{
+	struct backing_dev_info	*rt_bdi =
+		mp->m_rtdev_targp->bt_bdev->bd_disk->bdi;
+	struct backing_dev_info	*sb_bdi = mp->m_super->s_bdi;
+
+	sb_bdi->ra_pages = max(sb_bdi->ra_pages, rt_bdi->ra_pages);
+	sb_bdi->io_pages = max(sb_bdi->io_pages, rt_bdi->io_pages);
+}
+
 /*
  * Setup xfs_mount buffer target pointers based on superblock
  */
@@ -583,6 +606,7 @@ xfs_setup_devices(
 				mp->m_sb.sb_sectsize, mp->m_sb.sb_rblocks);
 		if (error)
 			return error;
+		xfs_update_bdi_rahead(mp);
 	}
 
 	return 0;
-- 
2.53.0

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Damien Le Moal]

On 6/23/26 23:21, Christoph Hellwig wrote:
> When using XFS with a main device on an SSD that stores metadata and a RT
> device to store data on a HDD, we fail to take the I/O sizes for the RT
> device into accounting, leading to up to 5% slower read performance when
> using an SSD for metadata vs storing data and metadata on the HDD.
> 
> Fix this up by taking the RT settings into account.  Note that this
> updates the BDI owned by the main device, and leaves those settings in
> place even when the file system is unmounted.  This is a bit unexpected
> but not different from manual tuning through sysfs (although that is only
> possible for the ra_pages value).
> 
> Reported-by: Filip Blagojevic <filip.blagojevic@wdc.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Until we have a better API to do this, given the performance improvements this
gives with HDDs, I am all for it.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Carlos Maiolino]

On Tue, Jun 23, 2026 at 04:21:06PM +0200, Christoph Hellwig wrote:
> When using XFS with a main device on an SSD that stores metadata and a RT
> device to store data on a HDD, we fail to take the I/O sizes for the RT
> device into accounting, leading to up to 5% slower read performance when
> using an SSD for metadata vs storing data and metadata on the HDD.
> 
> Fix this up by taking the RT settings into account.  Note that this
> updates the BDI owned by the main device, and leaves those settings in
> place even when the file system is unmounted.  This is a bit unexpected
> but not different from manual tuning through sysfs (although that is only
> possible for the ra_pages value).

Sorry a 'very late reply', but...
On a second thought, wouldn't be wise to cache the original value in
memory and restore it during unmount/filesystem shutdown?

I could send a patch to complement this one if you guys agree, otherwise
just ignore me.

> 
> Reported-by: Filip Blagojevic <filip.blagojevic@wdc.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/xfs_super.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index e6781f86d867..88edd3822872 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -546,6 +546,29 @@ xfs_open_devices(
>  	return error;
>  }
>  
> +/*
> + * When using a RT device some or all data I/O is using the RT device, but
> + * the BDI is inherited from the main data device.  When the underlying block
> + * device for the RT device has larger I/O sizes, the BDI settings might be
> + * incorrect, which is especially bad if the main device is a SSD and the
> + * RT device is a HDD, as the io_opt fixup in blk_apply_bdi_limits is missing
> + * for this case.
> + *
> + * Update the BDI values to the max of the data and RT device to cover our
> + * bases.
> + */
> +static void
> +xfs_update_bdi_rahead(
> +	struct xfs_mount	*mp)
> +{
> +	struct backing_dev_info	*rt_bdi =
> +		mp->m_rtdev_targp->bt_bdev->bd_disk->bdi;
> +	struct backing_dev_info	*sb_bdi = mp->m_super->s_bdi;
> +
> +	sb_bdi->ra_pages = max(sb_bdi->ra_pages, rt_bdi->ra_pages);
> +	sb_bdi->io_pages = max(sb_bdi->io_pages, rt_bdi->io_pages);
> +}
> +
>  /*
>   * Setup xfs_mount buffer target pointers based on superblock
>   */
> @@ -583,6 +606,7 @@ xfs_setup_devices(
>  				mp->m_sb.sb_sectsize, mp->m_sb.sb_rblocks);
>  		if (error)
>  			return error;
> +		xfs_update_bdi_rahead(mp);
>  	}
>  
>  	return 0;
> -- 
> 2.53.0
> 

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

On Mon, Jul 20, 2026 at 11:02:15AM +0200, Carlos Maiolino wrote:
> On Tue, Jun 23, 2026 at 04:21:06PM +0200, Christoph Hellwig wrote:
> > When using XFS with a main device on an SSD that stores metadata and a RT
> > device to store data on a HDD, we fail to take the I/O sizes for the RT
> > device into accounting, leading to up to 5% slower read performance when
> > using an SSD for metadata vs storing data and metadata on the HDD.
> > 
> > Fix this up by taking the RT settings into account.  Note that this
> > updates the BDI owned by the main device, and leaves those settings in
> > place even when the file system is unmounted.  This is a bit unexpected
> > but not different from manual tuning through sysfs (although that is only
> > possible for the ra_pages value).
> 
> Sorry a 'very late reply', but...
> On a second thought, wouldn't be wise to cache the original value in
> memory and restore it during unmount/filesystem shutdown?
> 
> I could send a patch to complement this one if you guys agree, otherwise
> just ignore me.

As mentioned this does seem like a valid option, there's tradeoff
both ways.  Although we'd also want a flag to avoid restoring them
if they were changed while mounted so it would get a bit more
complicated.  Happy to respin it for that if there is a general
preference.

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Carlos Maiolino]

On Mon, Jul 20, 2026 at 11:11:28AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 20, 2026 at 11:02:15AM +0200, Carlos Maiolino wrote:
> > On Tue, Jun 23, 2026 at 04:21:06PM +0200, Christoph Hellwig wrote:
> > > When using XFS with a main device on an SSD that stores metadata and a RT
> > > device to store data on a HDD, we fail to take the I/O sizes for the RT
> > > device into accounting, leading to up to 5% slower read performance when
> > > using an SSD for metadata vs storing data and metadata on the HDD.
> > > 
> > > Fix this up by taking the RT settings into account.  Note that this
> > > updates the BDI owned by the main device, and leaves those settings in
> > > place even when the file system is unmounted.  This is a bit unexpected
> > > but not different from manual tuning through sysfs (although that is only
> > > possible for the ra_pages value).
> > 
> > Sorry a 'very late reply', but...
> > On a second thought, wouldn't be wise to cache the original value in
> > memory and restore it during unmount/filesystem shutdown?
> > 
> > I could send a patch to complement this one if you guys agree, otherwise
> > just ignore me.
> 
> As mentioned this does seem like a valid option, there's tradeoff
> both ways.  Although we'd also want a flag to avoid restoring them
> if they were changed while mounted so it would get a bit more
> complicated.  Happy to respin it for that if there is a general
> preference.
> 

Sorry coming back late to it, I don't want to give you extra work after
we've already discussed the implementation.

I was going to merge this patch today, but it came to my mind that might
not be a good idea to just quietly update BDI settings while XFS is
using it and just keep whatever change we made persist after the mount.

I can still merge it this week and we decide what to do later or just wait a
bit for extra thoughts on this.
Perhaps let's see if we get other comments soon and we make a decision
later this week.

Re: update BDI {io,ra}_pages values based on the RT device limits

[Carlos Maiolino]

On Tue, Jun 23, 2026 at 04:21:05PM +0200, Christoph Hellwig wrote:
> Hi all,
> 
> we ran into a bit of a funny case where adding an SSD to store metadata
> to a (zoned) XFS file system reduced the performance vs using a HDD for
> both data and metadata.  It turns out this is due to readahead code
> looking at the BDI limits, including the io_pages value that can't be
> inspected or tuned from userspace.
> 
> This patch has the simplest fix for that by just updating the values from
> XFS, but for a long-term solution this feels a bit ugly.  Other, a lot
> more invasive options would be:
> 
> 
>   1) support multiple BDIs per file system.
> 
> 	This would work pretty well for XFS, as data for a given file is
> 	always entirely on one device, and the VFS writeback code is not
> 	used for metadata.  But it probably doesn't work well for other
> 	cases

Giving the current tendency of filesystems being multi-device, this
doesn't sound bad IMHO. Wouldn't accessing io_pages of each BDI also be
worth even for a journal dev? I wonder if what you ran into wouldn't be
possible if somebody would be using just a SSD for journal and a non-rt
XFS on a HDD or a different/slower device.

I don't know how stupid that sounds but perhaps it wouldn't be that
complicated to support multiple BDIs without making it unpleasant for
filesystems that don't care?
sb->bdi could be turned into a dynamic array and a new sb->s_devcount
fields to keep track of it on multi-device filesystems. Filesystems who
don't care about multiple BDIs would have it pointing to a single BDI
struct. Again I feel I'm missing something, so it might sound really
stupid :)

> 
>   2) stop propagating these values through the BDI
> 
> 	Have a way to query these parameters from the file system, either
> 	through a method if we want to be fully dynamic, or through fields
> 	instead of going through the BDI.  The downside would be that
> 	sysfs modifications of the readahead size would not work after
> 	the file system initially queried them.

It doesn't sound bad, but to me, not better than keeping multiple BDIs.
But my lack of knowledge on details about BDI handling might be hiding
something from me.

> 
> Thoughts?
> 

Re: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

On Wed, Jun 24, 2026 at 12:40:50PM +0200, Carlos Maiolino wrote:
> Giving the current tendency of filesystems being multi-device, this
> doesn't sound bad IMHO. Wouldn't accessing io_pages of each BDI also be
> worth even for a journal dev? I wonder if what you ran into wouldn't be
> possible if somebody would be using just a SSD for journal and a non-rt
> XFS on a HDD or a different/slower device.

Nothing looks at the value for the log device.

> 
> I don't know how stupid that sounds but perhaps it wouldn't be that
> complicated to support multiple BDIs without making it unpleasant for
> filesystems that don't care?
> sb->bdi could be turned into a dynamic array and a new sb->s_devcount
> fields to keep track of it on multi-device filesystems. Filesystems who
> don't care about multiple BDIs would have it pointing to a single BDI
> struct. Again I feel I'm missing something, so it might sound really
> stupid :)

This will get complicated really soon..

Re: update BDI {io,ra}_pages values based on the RT device limits

[Jan Kara]

Hi Christoph!

On Tue 23-06-26 16:21:05, Christoph Hellwig wrote:
> we ran into a bit of a funny case where adding an SSD to store metadata
> to a (zoned) XFS file system reduced the performance vs using a HDD for
> both data and metadata.  It turns out this is due to readahead code
> looking at the BDI limits, including the io_pages value that can't be
> inspected or tuned from userspace.
> 
> This patch has the simplest fix for that by just updating the values from
> XFS, but for a long-term solution this feels a bit ugly.  Other, a lot
> more invasive options would be:

A cleaner but still relatively simple way how to fix your problem would be
to do something similar like e.g. btrfs does. That is when you have a
filesystem with multiple backing devices, you create a new BDI (using
super_setup_bdi()) and set its parameters based on the combination of
devices you have.

The only downside to this is that blk-wbt has a layering violation in it
when it tries to guess whether there are task dirty-throttled for the
device which stops working for when the filesystem uses this synthetic bdi.
But I don't think that's too serious to worry about.

>   1) support multiple BDIs per file system.
> 
> 	This would work pretty well for XFS, as data for a given file is
> 	always entirely on one device, and the VFS writeback code is not
> 	used for metadata.  But it probably doesn't work well for other
> 	cases

Since looking up the bdi is abstracted through inode_to_bdi() (which
currently goes through the superblock), this would be relatively easy to do
but either the inode would have to store the bdi pointer or we'd have to
have an operation to query it. Just at this point I'm not fully convinced
the additional complexity / memory cost is worth it compared to what can be
achieved with a synthetic bdi.

>   2) stop propagating these values through the BDI
> 
> 	Have a way to query these parameters from the file system, either
> 	through a method if we want to be fully dynamic, or through fields
> 	instead of going through the BDI.  The downside would be that
> 	sysfs modifications of the readahead size would not work after
> 	the file system initially queried them.

Similarly as above. It makes sense but I'm not sure there are strong enough
usecases to justify this.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

On Wed, Jun 24, 2026 at 02:26:35PM +0200, Jan Kara wrote:
> A cleaner but still relatively simple way how to fix your problem would be
> to do something similar like e.g. btrfs does. That is when you have a
> filesystem with multiple backing devices, you create a new BDI (using
> super_setup_bdi()) and set its parameters based on the combination of
> devices you have.
> 
> The only downside to this is that blk-wbt has a layering violation in it
> when it tries to guess whether there are task dirty-throttled for the
> device which stops working for when the filesystem uses this synthetic bdi.
> But I don't think that's too serious to worry about.

The big downside of that is that it breaks the userspace ABI - any
previous changes to BDI paramters, most importantly the read-ahead size,
would now only apply to the BDI for s_bdev which isn't actually used
by anything.

And yeah, the blk-wbt thing actually looks really broken and could use
fixing..

> >   1) support multiple BDIs per file system.
> > 
> > 	This would work pretty well for XFS, as data for a given file is
> > 	always entirely on one device, and the VFS writeback code is not
> > 	used for metadata.  But it probably doesn't work well for other
> > 	cases
> 
> Since looking up the bdi is abstracted through inode_to_bdi() (which
> currently goes through the superblock), this would be relatively easy to do
> but either the inode would have to store the bdi pointer or we'd have to
> have an operation to query it. Just at this point I'm not fully convinced
> the additional complexity / memory cost is worth it compared to what can be
> achieved with a synthetic bdi.

Same.

> >   2) stop propagating these values through the BDI
> > 
> > 	Have a way to query these parameters from the file system, either
> > 	through a method if we want to be fully dynamic, or through fields
> > 	instead of going through the BDI.  The downside would be that
> > 	sysfs modifications of the readahead size would not work after
> > 	the file system initially queried them.
> 
> Similarly as above. It makes sense but I'm not sure there are strong enough
> usecases to justify this.

It would at least be a lot less complete than option 1.  And get us out of
a bit more of all that bdi weirdness.

Re: update BDI {io,ra}_pages values based on the RT device limits

[Jan Kara]

On Wed 24-06-26 15:49:50, Christoph Hellwig wrote:
> On Wed, Jun 24, 2026 at 02:26:35PM +0200, Jan Kara wrote:
> > A cleaner but still relatively simple way how to fix your problem would be
> > to do something similar like e.g. btrfs does. That is when you have a
> > filesystem with multiple backing devices, you create a new BDI (using
> > super_setup_bdi()) and set its parameters based on the combination of
> > devices you have.
> 
> The big downside of that is that it breaks the userspace ABI - any
> previous changes to BDI paramters, most importantly the read-ahead size,
> would now only apply to the BDI for s_bdev which isn't actually used
> by anything.

Hum, right. XFS users are used to tweak
/sys/block/<dev>/queue/read_ahead_kb
which would stop influencing anything. I guess that could indeed break some
people's expectations.

> > >   1) support multiple BDIs per file system.
> > > 
> > > 	This would work pretty well for XFS, as data for a given file is
> > > 	always entirely on one device, and the VFS writeback code is not
> > > 	used for metadata.  But it probably doesn't work well for other
> > > 	cases
> > 
> > Since looking up the bdi is abstracted through inode_to_bdi() (which
> > currently goes through the superblock), this would be relatively easy to do
> > but either the inode would have to store the bdi pointer or we'd have to
> > have an operation to query it. Just at this point I'm not fully convinced
> > the additional complexity / memory cost is worth it compared to what can be
> > achieved with a synthetic bdi.
> 
> Same.

One more idea: We already cache bdi's ra_pages in struct file_ra_state on
file open. It wouldn't be that hard to allow filesystem to override the
values in its open method (currently it isn't possible only because
file_ra_state_init() is called after ->open). For io_pages we currently
always go to the bdi so we'd have to add it to struct file_ra_state.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

On Thu, Jun 25, 2026 at 01:12:05PM +0200, Jan Kara wrote:
> Hum, right. XFS users are used to tweak
> /sys/block/<dev>/queue/read_ahead_kb
> which would stop influencing anything. I guess that could indeed break some
> people's expectations.

Yeah.

> One more idea: We already cache bdi's ra_pages in struct file_ra_state on
> file open. It wouldn't be that hard to allow filesystem to override the
> values in its open method (currently it isn't possible only because
> file_ra_state_init() is called after ->open). For io_pages we currently
> always go to the bdi so we'd have to add it to struct file_ra_state.

It has to be called after ->open because ->open can change
file->f_mapping.  Now we could require any instance changing it to also
call file_ra_state_init, but I think bloating every struct file with a
new field might not win a lot of friends.  OTOH having a local copy
of ra_pages but not io_pages is really weird.  But so is this whole
cascading set of indirections for the readahead parameters.

> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
---end quoted text---

Re: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

So, I guess we're stuck with this approach?  Or any other ideas?

On Tue, Jun 23, 2026 at 04:21:05PM +0200, Christoph Hellwig wrote:
> Hi all,
> 
> we ran into a bit of a funny case where adding an SSD to store metadata
> to a (zoned) XFS file system reduced the performance vs using a HDD for
> both data and metadata.  It turns out this is due to readahead code
> looking at the BDI limits, including the io_pages value that can't be
> inspected or tuned from userspace.
> 
> This patch has the simplest fix for that by just updating the values from
> XFS, but for a long-term solution this feels a bit ugly.  Other, a lot
> more invasive options would be:
> 
> 
>   1) support multiple BDIs per file system.
> 
> 	This would work pretty well for XFS, as data for a given file is
> 	always entirely on one device, and the VFS writeback code is not
> 	used for metadata.  But it probably doesn't work well for other
> 	cases
> 
>   2) stop propagating these values through the BDI
> 
> 	Have a way to query these parameters from the file system, either
> 	through a method if we want to be fully dynamic, or through fields
> 	instead of going through the BDI.  The downside would be that
> 	sysfs modifications of the readahead size would not work after
> 	the file system initially queried them.
> 
> Thoughts?
---end quoted text---

update BDI {io,ra}_pages values based on the RT device limits v2

[Christoph Hellwig]

Hi all,

we ran into a bit of a funny case where adding an SSD to store metadata
to a (zoned) XFS file system reduced the performance vs using a HDD for
both data and metadata.  It turns out this is due to readahead code
looking at the BDI limits, including the io_pages value that can't be
inspected or tuned from userspace.

Changes since v1:
 - restore the old value at unmount, unless the BDI values changed
   since mount

[PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

When using XFS with a main device on an SSD that stores metadata and a RT
device to store data on a HDD, we fail to take the I/O sizes for the RT
device into accounting, leading to up to 5% slower read performance when
using an SSD for metadata vs storing data and metadata on the HDD.

Fix this up by taking the RT settings into account at mount an restoring
the old settings at unmount time, unless the BDI settings have changed
from those set by XFS.

Reported-by: Filip Blagojevic <filip.blagojevic@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_mount.h |  7 ++++++
 fs/xfs/xfs_super.c | 53 +++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
index 66a02d1b9ad7..216a38a354e7 100644
--- a/fs/xfs/xfs_mount.h
+++ b/fs/xfs/xfs_mount.h
@@ -349,6 +349,13 @@ typedef struct xfs_mount {
 
 	/* Index of uuid record in the uuid xarray. */
 	unsigned int		m_uuid_table_index;
+
+	/*
+	 * Old io_pages/ra_pages valued in the main bdev BDI, and our initial
+	 * calculated values.
+	 */
+	unsigned long		m_old_io_pages, m_initial_io_pages;
+	unsigned long		m_old_ra_pages, m_initial_ra_pages;
 } xfs_mount_t;
 
 #define M_IGEO(mp)		(&(mp)->m_ino_geo)
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 8531d526fc44..63c4bcbe6c2b 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -548,6 +548,52 @@ xfs_open_devices(
 	return error;
 }
 
+/*
+ * When using a RT device some or all data I/O is using the RT device, but
+ * the BDI is inherited from the main data device.  When the underlying block
+ * device for the RT device has larger I/O sizes, the BDI settings might be
+ * incorrect, which is especially bad if the main device is a SSD and the
+ * RT device is a HDD, as the io_opt fixup in blk_apply_bdi_limits is missing
+ * for this case.
+ *
+ * Update the BDI values to the max of the data and RT device to cover our
+ * bases.
+ */
+static void
+xfs_update_bdi_rahead(
+	struct xfs_mount	*mp)
+{
+	struct backing_dev_info	*rt_bdi =
+		mp->m_rtdev_targp->bt_bdev->bd_disk->bdi;
+	struct backing_dev_info	*sb_bdi = mp->m_super->s_bdi;
+
+	mp->m_old_io_pages = sb_bdi->io_pages;
+	mp->m_old_ra_pages = sb_bdi->ra_pages;
+
+	sb_bdi->io_pages = mp->m_initial_io_pages =
+		max(sb_bdi->io_pages, rt_bdi->io_pages);
+	sb_bdi->ra_pages = mp->m_initial_ra_pages =
+		max(sb_bdi->ra_pages, rt_bdi->ra_pages);
+}
+
+static void
+xfs_restore_bdi_rahead(
+	struct xfs_mount	*mp)
+{
+	struct backing_dev_info	*sb_bdi = mp->m_super->s_bdi;
+
+	if (sb_bdi->io_pages == mp->m_initial_io_pages)
+		sb_bdi->io_pages = mp->m_old_io_pages;
+	else
+		xfs_info(mp, "io_pages changed from %lu to %lu, not restoring.",
+				mp->m_initial_io_pages, sb_bdi->io_pages);
+	if (sb_bdi->ra_pages == mp->m_initial_ra_pages)
+		sb_bdi->ra_pages = mp->m_old_ra_pages;
+	else
+		xfs_info(mp, "ra_pages changed from %lu to %lu, not restoring.",
+				mp->m_initial_ra_pages, sb_bdi->ra_pages);
+}
+
 /*
  * Setup xfs_mount buffer target pointers based on superblock
  */
@@ -585,6 +631,7 @@ xfs_setup_devices(
 				mp->m_sb.sb_sectsize, mp->m_sb.sb_rblocks);
 		if (error)
 			return error;
+		xfs_update_bdi_rahead(mp);
 	}
 
 	return 0;
@@ -2283,8 +2330,12 @@ static void
 xfs_kill_sb(
 	struct super_block		*sb)
 {
+	struct xfs_mount		*mp = XFS_M(sb);
+
+	if (mp->m_rtdev_targp && mp->m_rtdev_targp != mp->m_ddev_targp)
+		xfs_restore_bdi_rahead(mp);
 	kill_block_super(sb);
-	xfs_mount_free(XFS_M(sb));
+	xfs_mount_free(mp);
 }
 
 static struct file_system_type xfs_fs_type = {
-- 
2.53.0

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Damien Le Moal]

On 7/20/26 23:08, Christoph Hellwig wrote:
> When using XFS with a main device on an SSD that stores metadata and a RT
> device to store data on a HDD, we fail to take the I/O sizes for the RT
> device into accounting, leading to up to 5% slower read performance when
> using an SSD for metadata vs storing data and metadata on the HDD.
> 
> Fix this up by taking the RT settings into account at mount an restoring
> the old settings at unmount time, unless the BDI settings have changed
> from those set by XFS.
> 
> Reported-by: Filip Blagojevic <filip.blagojevic@wdc.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

[...]

> +/*
> + * When using a RT device some or all data I/O is using the RT device, but
> + * the BDI is inherited from the main data device.  When the underlying block
> + * device for the RT device has larger I/O sizes, the BDI settings might be
> + * incorrect, which is especially bad if the main device is a SSD and the
> + * RT device is a HDD, as the io_opt fixup in blk_apply_bdi_limits is missing
> + * for this case.
> + *
> + * Update the BDI values to the max of the data and RT device to cover our

s/data/main ?
I am still confused about the proper name for the device holding metadata :)

Other than this, this looks OK to me.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig]

On Tue, Jul 21, 2026 at 08:07:40AM +0900, Damien Le Moal wrote:
> > + * Update the BDI values to the max of the data and RT device to cover our
> 
> s/data/main ?
> I am still confused about the proper name for the device holding metadata :)
> 
> Other than this, this looks OK to me.

Historically the main device is called the data device, which is
also reflected in all kinds of field naming.  But yes, it is confusing
especially for zoned xfs setups.  Maybe I should do a little global
naming sweep..

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Carlos Maiolino]

On Tue, Jul 21, 2026 at 06:30:11AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 21, 2026 at 08:07:40AM +0900, Damien Le Moal wrote:
> > > + * Update the BDI values to the max of the data and RT device to cover our
> > 
> > s/data/main ?
> > I am still confused about the proper name for the device holding metadata :)
> > 
> > Other than this, this looks OK to me.
> 
> Historically the main device is called the data device, which is
> also reflected in all kinds of field naming.  But yes, it is confusing
> especially for zoned xfs setups.  Maybe I should do a little global
> naming sweep..
> 
> 

+1, please keep /data/ here, this makes much more sense in xfs lingo...
Perhaps we should start naming them to something like ndata (for normal
data) and zdata for zoned data, but that's talk for another thread.

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Darrick J. Wong]

On Tue, Jul 21, 2026 at 11:23:29AM +0200, Carlos Maiolino wrote:
> On Tue, Jul 21, 2026 at 06:30:11AM +0200, Christoph Hellwig wrote:
> > On Tue, Jul 21, 2026 at 08:07:40AM +0900, Damien Le Moal wrote:
> > > > + * Update the BDI values to the max of the data and RT device to cover our
> > > 
> > > s/data/main ?
> > > I am still confused about the proper name for the device holding metadata :)
> > > 
> > > Other than this, this looks OK to me.
> > 
> > Historically the main device is called the data device, which is
> > also reflected in all kinds of field naming.  But yes, it is confusing
> > especially for zoned xfs setups.  Maybe I should do a little global
> > naming sweep..
> > 
> > 
> 
> +1, please keep /data/ here, this makes much more sense in xfs lingo...
> Perhaps we should start naming them to something like ndata (for normal
> data) and zdata for zoned data, but that's talk for another thread.

I've been trying to be consistent at calling them the 'datadev' and
'rtdev' (no spaces) so it's more obvious that I'm using a jargon.  But
'rt' makes no sense these days and I never did come up with a good
retcon for it though.

"RelaTive"?  Because the rtdev is "related" to the datadev by metadata?

:D

--D

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Carlos Maiolino]

On Mon, Jul 20, 2026 at 04:08:47PM +0200, Christoph Hellwig wrote:
> When using XFS with a main device on an SSD that stores metadata and a RT
> device to store data on a HDD, we fail to take the I/O sizes for the RT
> device into accounting, leading to up to 5% slower read performance when
> using an SSD for metadata vs storing data and metadata on the HDD.
> 
> Fix this up by taking the RT settings into account at mount an restoring
> the old settings at unmount time, unless the BDI settings have changed
> from those set by XFS.
> 
> Reported-by: Filip Blagojevic <filip.blagojevic@wdc.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>


> ---
>  fs/xfs/xfs_mount.h |  7 ++++++
>  fs/xfs/xfs_super.c | 53 +++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> index 66a02d1b9ad7..216a38a354e7 100644
> --- a/fs/xfs/xfs_mount.h
> +++ b/fs/xfs/xfs_mount.h
> @@ -349,6 +349,13 @@ typedef struct xfs_mount {
>  
>  	/* Index of uuid record in the uuid xarray. */
>  	unsigned int		m_uuid_table_index;
> +
> +	/*
> +	 * Old io_pages/ra_pages valued in the main bdev BDI, and our initial
> +	 * calculated values.
> +	 */
> +	unsigned long		m_old_io_pages, m_initial_io_pages;
> +	unsigned long		m_old_ra_pages, m_initial_ra_pages;
>  } xfs_mount_t;
>  
>  #define M_IGEO(mp)		(&(mp)->m_ino_geo)
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index 8531d526fc44..63c4bcbe6c2b 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -548,6 +548,52 @@ xfs_open_devices(
>  	return error;
>  }
>  
> +/*
> + * When using a RT device some or all data I/O is using the RT device, but
> + * the BDI is inherited from the main data device.  When the underlying block
> + * device for the RT device has larger I/O sizes, the BDI settings might be
> + * incorrect, which is especially bad if the main device is a SSD and the
> + * RT device is a HDD, as the io_opt fixup in blk_apply_bdi_limits is missing
> + * for this case.
> + *
> + * Update the BDI values to the max of the data and RT device to cover our
> + * bases.
> + */
> +static void
> +xfs_update_bdi_rahead(
> +	struct xfs_mount	*mp)
> +{
> +	struct backing_dev_info	*rt_bdi =
> +		mp->m_rtdev_targp->bt_bdev->bd_disk->bdi;
> +	struct backing_dev_info	*sb_bdi = mp->m_super->s_bdi;
> +
> +	mp->m_old_io_pages = sb_bdi->io_pages;
> +	mp->m_old_ra_pages = sb_bdi->ra_pages;
> +
> +	sb_bdi->io_pages = mp->m_initial_io_pages =
> +		max(sb_bdi->io_pages, rt_bdi->io_pages);
> +	sb_bdi->ra_pages = mp->m_initial_ra_pages =
> +		max(sb_bdi->ra_pages, rt_bdi->ra_pages);
> +}
> +
> +static void
> +xfs_restore_bdi_rahead(
> +	struct xfs_mount	*mp)
> +{
> +	struct backing_dev_info	*sb_bdi = mp->m_super->s_bdi;
> +
> +	if (sb_bdi->io_pages == mp->m_initial_io_pages)
> +		sb_bdi->io_pages = mp->m_old_io_pages;
> +	else
> +		xfs_info(mp, "io_pages changed from %lu to %lu, not restoring.",
> +				mp->m_initial_io_pages, sb_bdi->io_pages);
> +	if (sb_bdi->ra_pages == mp->m_initial_ra_pages)
> +		sb_bdi->ra_pages = mp->m_old_ra_pages;
> +	else
> +		xfs_info(mp, "ra_pages changed from %lu to %lu, not restoring.",
> +				mp->m_initial_ra_pages, sb_bdi->ra_pages);
> +}
> +
>  /*
>   * Setup xfs_mount buffer target pointers based on superblock
>   */
> @@ -585,6 +631,7 @@ xfs_setup_devices(
>  				mp->m_sb.sb_sectsize, mp->m_sb.sb_rblocks);
>  		if (error)
>  			return error;
> +		xfs_update_bdi_rahead(mp);
>  	}
>  
>  	return 0;
> @@ -2283,8 +2330,12 @@ static void
>  xfs_kill_sb(
>  	struct super_block		*sb)
>  {
> +	struct xfs_mount		*mp = XFS_M(sb);
> +
> +	if (mp->m_rtdev_targp && mp->m_rtdev_targp != mp->m_ddev_targp)
> +		xfs_restore_bdi_rahead(mp);
>  	kill_block_super(sb);
> -	xfs_mount_free(XFS_M(sb));
> +	xfs_mount_free(mp);
>  }
>  
>  static struct file_system_type xfs_fs_type = {
> -- 
> 2.53.0
> 
> 

Re: [PATCH] xfs: update BDI {io,ra}_pages values based on the RT device limits

[Carlos Maiolino]

On Mon, 20 Jul 2026 16:08:47 +0200, Christoph Hellwig wrote:
> When using XFS with a main device on an SSD that stores metadata and a RT
> device to store data on a HDD, we fail to take the I/O sizes for the RT
> device into accounting, leading to up to 5% slower read performance when
> using an SSD for metadata vs storing data and metadata on the HDD.
> 
> Fix this up by taking the RT settings into account at mount an restoring
> the old settings at unmount time, unless the BDI settings have changed
> from those set by XFS.
> 
> [...]

Applied to for-next, thanks!

[1/1] xfs: update BDI {io,ra}_pages values based on the RT device limits
      commit: 39de8c9f3e4bc059bb0bc85a39affcf52664c1ed

Best regards,
-- 
Carlos Maiolino <cem@kernel.org>