[PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Damien Le Moal]

Enabling XFS realtime subvolume (XFS_RT) is mandatory to support zoned
block devices. If CONFIG_BLK_DEV_ZONED is enabled, automatically select
CONFIG_XFS_RT to allow users to format zoned block devices using XFS.

Also improve the description of the XFS_RT configuration option to
document that it is reuired for zoned block devices.

Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
---
 fs/xfs/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig
index ae0ca6858496..c77118e96b82 100644
--- a/fs/xfs/Kconfig
+++ b/fs/xfs/Kconfig
@@ -5,6 +5,7 @@ config XFS_FS
 	select EXPORTFS
 	select CRC32
 	select FS_IOMAP
+	select XFS_RT if BLK_DEV_ZONED
 	help
 	  XFS is a high performance journaling filesystem which originated
 	  on the SGI IRIX platform.  It is completely multi-threaded, can
@@ -116,6 +117,15 @@ config XFS_RT
 	  from all other requests, and this can be done quite transparently
 	  to applications via the inherit-realtime directory inode flag.
 
+	  This option is mandatory to support zoned block devices. For these
+	  devices, the realtime subvolume must be backed by a zoned block
+	  device and a regular block device used as the main device (for
+	  metadata). If the zoned block device is a host-managed SMR hard-disk
+	  containing conventional zones at the beginning of its address space,
+	  XFS will use the disk conventional zones as the main device and the
+	  remaining sequential write required zones as the backing storage for
+	  the realtime subvolume.
+
 	  See the xfs man page in section 5 for additional information.
 
 	  If unsure, say N.
-- 
2.50.1

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Carlos Maiolino]

On Wed, Aug 06, 2025 at 01:34:49PM +0900, Damien Le Moal wrote:
> Enabling XFS realtime subvolume (XFS_RT) is mandatory to support zoned
> block devices. If CONFIG_BLK_DEV_ZONED is enabled, automatically select
> CONFIG_XFS_RT to allow users to format zoned block devices using XFS.
> 
> Also improve the description of the XFS_RT configuration option to
> document that it is reuired for zoned block devices.
> 
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
>  fs/xfs/Kconfig | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig
> index ae0ca6858496..c77118e96b82 100644
> --- a/fs/xfs/Kconfig
> +++ b/fs/xfs/Kconfig
> @@ -5,6 +5,7 @@ config XFS_FS
>  	select EXPORTFS
>  	select CRC32
>  	select FS_IOMAP
> +	select XFS_RT if BLK_DEV_ZONED

This looks weird to me.
Obligating users to enable an optional feature in xfs if their
kernel are configured with a specific block dev feature doesn't
sound the right thing to do.
What if the user doesn't want to use XFS RT devices even though
BLK_DEV_ZONED is enabled, for whatever other purpose?

Forcing enabling a filesystem configuration because a specific block
feature is enabled doesn't sound the right thing to do IMHO.

>  	help
>  	  XFS is a high performance journaling filesystem which originated
>  	  on the SGI IRIX platform.  It is completely multi-threaded, can
> @@ -116,6 +117,15 @@ config XFS_RT
>  	  from all other requests, and this can be done quite transparently
>  	  to applications via the inherit-realtime directory inode flag.
> 
> +	  This option is mandatory to support zoned block devices.

What if a user wants to use another filesystem for ZBDs instead of XFS, but
still want to have XFS enabled? I haven't followed ZBD work too close,
but looking at zonedstorage.io, I see that at least btrfs also supports
zoned storage.
So, what if somebody wants to have btrfs enabled to use zoned storage,
but also provides xfs without RT support?

Again, I don't think forcefully enabling XFS_RT is the right thing to
do.

> For these
> +	  devices, the realtime subvolume must be backed by a zoned block
> +	  device and a regular block device used as the main device (for
> +	  metadata). If the zoned block device is a host-managed SMR hard-disk
> +	  containing conventional zones at the beginning of its address space,
> +	  XFS will use the disk conventional zones as the main device and the
> +	  remaining sequential write required zones as the backing storage for
> +	  the realtime subvolume.
> +
>  	  See the xfs man page in section 5 for additional information.

		Does it? Only section I see mentions of zoned storage is
		the mkfs man page. Am I missing something?

Carlos

> 
>  	  If unsure, say N.
> --
> 2.50.1
> 

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Damien Le Moal]

On 8/6/25 4:46 PM, Carlos Maiolino wrote:
> On Wed, Aug 06, 2025 at 01:34:49PM +0900, Damien Le Moal wrote:
>> Enabling XFS realtime subvolume (XFS_RT) is mandatory to support zoned
>> block devices. If CONFIG_BLK_DEV_ZONED is enabled, automatically select
>> CONFIG_XFS_RT to allow users to format zoned block devices using XFS.
>>
>> Also improve the description of the XFS_RT configuration option to
>> document that it is reuired for zoned block devices.
>>
>> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
>> ---
>>  fs/xfs/Kconfig | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig
>> index ae0ca6858496..c77118e96b82 100644
>> --- a/fs/xfs/Kconfig
>> +++ b/fs/xfs/Kconfig
>> @@ -5,6 +5,7 @@ config XFS_FS
>>  	select EXPORTFS
>>  	select CRC32
>>  	select FS_IOMAP
>> +	select XFS_RT if BLK_DEV_ZONED
> 
> This looks weird to me.
> Obligating users to enable an optional feature in xfs if their
> kernel are configured with a specific block dev feature doesn't
> sound the right thing to do.
> What if the user doesn't want to use XFS RT devices even though
> BLK_DEV_ZONED is enabled, for whatever other purpose?

This does not force the user to use XFS_RT, it only makes that feature
available for someone wanting to format e.g. an SMR HDD with XFS.
I am not sure how "costly" enabling XFS_RT is if it is not used. There is for
sure some xfs code size increase, but beside that, is it really an issue ?

> Forcing enabling a filesystem configuration because a specific block
> feature is enabled doesn't sound the right thing to do IMHO.

Well, it is nicer for the average user who may not be aware that this feature
is needed for zoned block devices. mkfs.xfs will not complain and format an SMR
HDD even if XFS_RT is disabled. But then mount will fail with a message that
the average user will have a hard time understanding. This is the goal of this
patch: making life easier for the user by ensuring that features that are
needed to use XFS on zoned storage are all present, if zoned storage is
supported by the kernel.

> 
>>  	help
>>  	  XFS is a high performance journaling filesystem which originated
>>  	  on the SGI IRIX platform.  It is completely multi-threaded, can
>> @@ -116,6 +117,15 @@ config XFS_RT
>>  	  from all other requests, and this can be done quite transparently
>>  	  to applications via the inherit-realtime directory inode flag.
>>
>> +	  This option is mandatory to support zoned block devices.
> 
> What if a user wants to use another filesystem for ZBDs instead of XFS, but
> still want to have XFS enabled? I haven't followed ZBD work too close,
> but looking at zonedstorage.io, I see that at least btrfs also supports
> zoned storage.
> So, what if somebody wants to have btrfs enabled to use zoned storage,
> but also provides xfs without RT support?
> 
> Again, I don't think forcefully enabling XFS_RT is the right thing to
> do.
> 
>> For these
>> +	  devices, the realtime subvolume must be backed by a zoned block
>> +	  device and a regular block device used as the main device (for
>> +	  metadata). If the zoned block device is a host-managed SMR hard-disk
>> +	  containing conventional zones at the beginning of its address space,
>> +	  XFS will use the disk conventional zones as the main device and the
>> +	  remaining sequential write required zones as the backing storage for
>> +	  the realtime subvolume.
>> +
>>  	  See the xfs man page in section 5 for additional information.
> 
> 		Does it? Only section I see mentions of zoned storage is
> 		the mkfs man page. Am I missing something?

I have not changed this line. It was there and I kept it as-is.
Checking xfsprogs v6.15 man pages, at least mkfs.xfs page is a little light on
comments about zoned block device support. Will improve that there.

> 
> Carlos
> 
>>
>>  	  If unsure, say N.
>> --
>> 2.50.1
>>


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Carlos Maiolino]

On Wed, Aug 06, 2025 at 05:04:05PM +0900, Damien Le Moal wrote:
> On 8/6/25 4:46 PM, Carlos Maiolino wrote:
> > On Wed, Aug 06, 2025 at 01:34:49PM +0900, Damien Le Moal wrote:
> >> Enabling XFS realtime subvolume (XFS_RT) is mandatory to support zoned
> >> block devices. If CONFIG_BLK_DEV_ZONED is enabled, automatically select
> >> CONFIG_XFS_RT to allow users to format zoned block devices using XFS.
> >>
> >> Also improve the description of the XFS_RT configuration option to
> >> document that it is reuired for zoned block devices.
> >>
> >> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> >> ---
> >>  fs/xfs/Kconfig | 10 ++++++++++
> >>  1 file changed, 10 insertions(+)
> >>
> >> diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig
> >> index ae0ca6858496..c77118e96b82 100644
> >> --- a/fs/xfs/Kconfig
> >> +++ b/fs/xfs/Kconfig
> >> @@ -5,6 +5,7 @@ config XFS_FS
> >>  	select EXPORTFS
> >>  	select CRC32
> >>  	select FS_IOMAP
> >> +	select XFS_RT if BLK_DEV_ZONED
> >
> > This looks weird to me.
> > Obligating users to enable an optional feature in xfs if their
> > kernel are configured with a specific block dev feature doesn't
> > sound the right thing to do.
> > What if the user doesn't want to use XFS RT devices even though
> > BLK_DEV_ZONED is enabled, for whatever other purpose?
> 
> This does not force the user to use XFS_RT, it only makes that feature
> available for someone wanting to format e.g. an SMR HDD with XFS.
> I am not sure how "costly" enabling XFS_RT is if it is not used. There is for
> sure some xfs code size increase, but beside that, is it really an issue ?

The problem I want to raise is not about code size increase, but about
having XFS_RT tied with BLK_DEV_ZONED.
I know it doesn't force users to use XFS_RT, but there are distros out
there which purposely disables XFS_RT, but at the same time might want
BLK_DEV_ZONED enabled to use, for example with btrfs.

> 
> > Forcing enabling a filesystem configuration because a specific block
> > feature is enabled doesn't sound the right thing to do IMHO.
> 
> Well, it is nicer for the average user who may not be aware that this feature
> is needed for zoned block devices.

But for the average user, wouldn't be the distribution's responsibility
to actually properly enable/disable the correct configuration?
I don't see average users building their own kernel, even more actually
using host-managed/host-aware disks.

> mkfs.xfs will not complain and format an SMR
> HDD even if XFS_RT is disabled.

Well, sure, you can't tie the disk to a single machine/kernel.

> But then mount will fail with a message that
> the average user will have a hard time understanding.

Then perhaps the right thing to do is fix the message?

> This is the goal of this
> patch: making life easier for the user by ensuring that features that are
> needed to use XFS on zoned storage are all present, if zoned storage is
> supported by the kernel.

I see, but this is also tying XFS_RT with BLK_DEV_ZONED, which is my
concern here. Users (read Distros) might not actually want to have
XFS_RT enabled even if they do have BLK_DEV_ZONED.

> 
> >
> >>  	help
> >>  	  XFS is a high performance journaling filesystem which originated
> >>  	  on the SGI IRIX platform.  It is completely multi-threaded, can
> >> @@ -116,6 +117,15 @@ config XFS_RT
> >>  	  from all other requests, and this can be done quite transparently
> >>  	  to applications via the inherit-realtime directory inode flag.
> >>
> >> +	  This option is mandatory to support zoned block devices.
> >
> > What if a user wants to use another filesystem for ZBDs instead of XFS, but
> > still want to have XFS enabled? I haven't followed ZBD work too close,
> > but looking at zonedstorage.io, I see that at least btrfs also supports
> > zoned storage.
> > So, what if somebody wants to have btrfs enabled to use zoned storage,
> > but also provides xfs without RT support?
> >
> > Again, I don't think forcefully enabling XFS_RT is the right thing to
> > do.
> >
> >> For these
> >> +	  devices, the realtime subvolume must be backed by a zoned block
> >> +	  device and a regular block device used as the main device (for
> >> +	  metadata). If the zoned block device is a host-managed SMR hard-disk
> >> +	  containing conventional zones at the beginning of its address space,
> >> +	  XFS will use the disk conventional zones as the main device and the
> >> +	  remaining sequential write required zones as the backing storage for
> >> +	  the realtime subvolume.
> >> +
> >>  	  See the xfs man page in section 5 for additional information.
> >
> > 		Does it? Only section I see mentions of zoned storage is
> > 		the mkfs man page. Am I missing something?
> 
> I have not changed this line. It was there and I kept it as-is.
> Checking xfsprogs v6.15 man pages, at least mkfs.xfs page is a little light on
> comments about zoned block device support. Will improve that there.

You didn't change, but the overall context that line referred to did so
it got misleading IMHO, reason I pointed it out.

Cheers,
Carlos

> 
> >
> > Carlos
> >
> >>
> >>  	  If unsure, say N.
> >> --
> >> 2.50.1
> >>
> 
> 
> --
> Damien Le Moal
> Western Digital Research

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Damien Le Moal]

On 8/6/25 5:45 PM, Carlos Maiolino wrote:
>> This does not force the user to use XFS_RT, it only makes that feature
>> available for someone wanting to format e.g. an SMR HDD with XFS.
>> I am not sure how "costly" enabling XFS_RT is if it is not used. There is for
>> sure some xfs code size increase, but beside that, is it really an issue ?
> 
> The problem I want to raise is not about code size increase, but about
> having XFS_RT tied with BLK_DEV_ZONED.
> I know it doesn't force users to use XFS_RT, but there are distros out
> there which purposely disables XFS_RT, but at the same time might want
> BLK_DEV_ZONED enabled to use, for example with btrfs.

Yes. Fedora is one. With it, we can use btrfs on zoned devices (and zonefs too)
but not XFS because they do not enable XFS_RT. So I can send a patch for their
kernel config to see if they would accept it. And do the same for many other
distros that have a similar config.

Or this patch to solve this in one go...

>>> Forcing enabling a filesystem configuration because a specific block
>>> feature is enabled doesn't sound the right thing to do IMHO.
>>
>> Well, it is nicer for the average user who may not be aware that this feature
>> is needed for zoned block devices.
> 
> But for the average user, wouldn't be the distribution's responsibility
> to actually properly enable/disable the correct configuration?
> I don't see average users building their own kernel, even more actually
> using host-managed/host-aware disks.

Yes, getting XFS_RT enabled through distros is the other solution. A lot more
painful though.

> 
>> mkfs.xfs will not complain and format an SMR
>> HDD even if XFS_RT is disabled.
> 
> Well, sure, you can't tie the disk to a single machine/kernel.
> 
>> But then mount will fail with a message that
>> the average user will have a hard time understanding.
> 
> Then perhaps the right thing to do is fix the message?

Sure, that can be done.

>> This is the goal of this
>> patch: making life easier for the user by ensuring that features that are
>> needed to use XFS on zoned storage are all present, if zoned storage is
>> supported by the kernel.
> 
> I see, but this is also tying XFS_RT with BLK_DEV_ZONED, which is my
> concern here. Users (read Distros) might not actually want to have
> XFS_RT enabled even if they do have BLK_DEV_ZONED.

Hmmm... which would be a problem. But I guess I have to take that to the distros ?

So is it a hard no for the XFS_RT automatic select ?

At the very least, I will send a v2 with the KConfig help update only to
clarify the XFS_RT requirement for zoned devices.

>>>> For these
>>>> +	  devices, the realtime subvolume must be backed by a zoned block
>>>> +	  device and a regular block device used as the main device (for
>>>> +	  metadata). If the zoned block device is a host-managed SMR hard-disk
>>>> +	  containing conventional zones at the beginning of its address space,
>>>> +	  XFS will use the disk conventional zones as the main device and the
>>>> +	  remaining sequential write required zones as the backing storage for
>>>> +	  the realtime subvolume.
>>>> +
>>>>  	  See the xfs man page in section 5 for additional information.
>>>
>>> 		Does it? Only section I see mentions of zoned storage is
>>> 		the mkfs man page. Am I missing something?
>>
>> I have not changed this line. It was there and I kept it as-is.
>> Checking xfsprogs v6.15 man pages, at least mkfs.xfs page is a little light on
>> comments about zoned block device support. Will improve that there.
> 
> You didn't change, but the overall context that line referred to did so
> it got misleading IMHO, reason I pointed it out.

OK. I can keep it in the same place it was and add the zoned device
clarification after it.



-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Carlos Maiolino]

Hi Damien.

On Wed, Aug 06, 2025 at 06:35:17PM +0900, Damien Le Moal wrote:
> On 8/6/25 5:45 PM, Carlos Maiolino wrote:
> >> This does not force the user to use XFS_RT, it only makes that feature
> >> available for someone wanting to format e.g. an SMR HDD with XFS.
> >> I am not sure how "costly" enabling XFS_RT is if it is not used. There is for
> >> sure some xfs code size increase, but beside that, is it really an issue ?
> >
> > The problem I want to raise is not about code size increase, but about
> > having XFS_RT tied with BLK_DEV_ZONED.
> > I know it doesn't force users to use XFS_RT, but there are distros out
> > there which purposely disables XFS_RT, but at the same time might want
> > BLK_DEV_ZONED enabled to use, for example with btrfs.
> 
> Yes. Fedora is one. With it, we can use btrfs on zoned devices (and zonefs too)
> but not XFS because they do not enable XFS_RT.

$ grep XFS_RT /boot/config-6.15.8-200.fc42.x86_64
CONFIG_XFS_RT=y

Fedora do Enable XFS_RT :-)

> So I can send a patch for their
> kernel config to see if they would accept it. And do the same for many other
> distros that have a similar config.
> 
> Or this patch to solve this in one go...

I don't think this is a solution. Offloading distributions
responsibility to the upstream projects is almost never a good idea.
While you fix a problem for one distro, you cause a problem in another.

> 
> >>> Forcing enabling a filesystem configuration because a specific block
> >>> feature is enabled doesn't sound the right thing to do IMHO.
> >>
> >> Well, it is nicer for the average user who may not be aware that this feature
> >> is needed for zoned block devices.
> >
> > But for the average user, wouldn't be the distribution's responsibility
> > to actually properly enable/disable the correct configuration?
> > I don't see average users building their own kernel, even more actually
> > using host-managed/host-aware disks.
> 
> Yes, getting XFS_RT enabled through distros is the other solution. A lot more
> painful though.

I consider removing the freedom of distributions to choose what they
want/not want to enable painful. With this patch, any distribution that
wants to not enable XFS_RT with zoned devices will need to custom patch
their kernels, and this create a lot of technical debt, specially for
non-mainstream distributions which don't have enough people working on
them.

Maintaining a kernel config file is way less complicated than keeping a
stack of custom patches, and ensuring the same patches will be available
on the next releases.

Yes, might not be the best scenario to go and convince your distro of
choice to enable this or that kernel option, but then offloading this to
kernel maintainers just because your distro doesn't do it is not the
right thing to do.


> 
> >
> >> mkfs.xfs will not complain and format an SMR
> >> HDD even if XFS_RT is disabled.
> >
> > Well, sure, you can't tie the disk to a single machine/kernel.
> >
> >> But then mount will fail with a message that
> >> the average user will have a hard time understanding.
> >
> > Then perhaps the right thing to do is fix the message?
> 
> Sure, that can be done.
> 
> >> This is the goal of this
> >> patch: making life easier for the user by ensuring that features that are
> >> needed to use XFS on zoned storage are all present, if zoned storage is
> >> supported by the kernel.
> >
> > I see, but this is also tying XFS_RT with BLK_DEV_ZONED, which is my
> > concern here. Users (read Distros) might not actually want to have
> > XFS_RT enabled even if they do have BLK_DEV_ZONED.
> 
> Hmmm... which would be a problem. But I guess I have to take that to the distros ?
> 
> So is it a hard no for the XFS_RT automatic select ?

I'm always fine changing my mind (even if I need to knock my head on
the desk a few times before). But unless we have a good reason to remove
distributions the possibility to have zoned devices enabled without
XFS_RT, in lieu of distributions that don't want to bother maintaining
their configuration files, this is a hard no from me.

And I don't consider "changing the config file of a distribution is
painful" as a good reason.

Carlos

> 
> At the very least, I will send a v2 with the KConfig help update only to
> clarify the XFS_RT requirement for zoned devices.
> 
> >>>> For these
> >>>> +	  devices, the realtime subvolume must be backed by a zoned block
> >>>> +	  device and a regular block device used as the main device (for
> >>>> +	  metadata). If the zoned block device is a host-managed SMR hard-disk
> >>>> +	  containing conventional zones at the beginning of its address space,
> >>>> +	  XFS will use the disk conventional zones as the main device and the
> >>>> +	  remaining sequential write required zones as the backing storage for
> >>>> +	  the realtime subvolume.
> >>>> +
> >>>>  	  See the xfs man page in section 5 for additional information.
> >>>
> >>> 		Does it? Only section I see mentions of zoned storage is
> >>> 		the mkfs man page. Am I missing something?
> >>
> >> I have not changed this line. It was there and I kept it as-is.
> >> Checking xfsprogs v6.15 man pages, at least mkfs.xfs page is a little light on
> >> comments about zoned block device support. Will improve that there.
> >
> > You didn't change, but the overall context that line referred to did so
> > it got misleading IMHO, reason I pointed it out.
> 
> OK. I can keep it in the same place it was and add the zoned device
> clarification after it.
> 
> 
> 
> --
> Damien Le Moal
> Western Digital Research
> 

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Damien Le Moal]

On 8/7/25 16:33, Carlos Maiolino wrote:
>>> The problem I want to raise is not about code size increase, but about
>>> having XFS_RT tied with BLK_DEV_ZONED.
>>> I know it doesn't force users to use XFS_RT, but there are distros out
>>> there which purposely disables XFS_RT, but at the same time might want
>>> BLK_DEV_ZONED enabled to use, for example with btrfs.
>>
>> Yes. Fedora is one. With it, we can use btrfs on zoned devices (and zonefs too)
>> but not XFS because they do not enable XFS_RT.
> 
> $ grep XFS_RT /boot/config-6.15.8-200.fc42.x86_64
> CONFIG_XFS_RT=y
> 
> Fedora do Enable XFS_RT :-)

Weird. Checked on my end and yes, it is enabled. Last time I checked, it was
not... Maybe I made a mistake when checking.

>> So I can send a patch for their
>> kernel config to see if they would accept it. And do the same for many other
>> distros that have a similar config.
>>
>> Or this patch to solve this in one go...
> 
> I don't think this is a solution. Offloading distributions
> responsibility to the upstream projects is almost never a good idea.
> While you fix a problem for one distro, you cause a problem in another.

OK.

> 
>>
>>>>> Forcing enabling a filesystem configuration because a specific block
>>>>> feature is enabled doesn't sound the right thing to do IMHO.
>>>>
>>>> Well, it is nicer for the average user who may not be aware that this feature
>>>> is needed for zoned block devices.
>>>
>>> But for the average user, wouldn't be the distribution's responsibility
>>> to actually properly enable/disable the correct configuration?
>>> I don't see average users building their own kernel, even more actually
>>> using host-managed/host-aware disks.
>>
>> Yes, getting XFS_RT enabled through distros is the other solution. A lot more
>> painful though.
> 
> I consider removing the freedom of distributions to choose what they
> want/not want to enable painful. With this patch, any distribution that
> wants to not enable XFS_RT with zoned devices will need to custom patch
> their kernels, and this create a lot of technical debt, specially for
> non-mainstream distributions which don't have enough people working on
> them.
> 
> Maintaining a kernel config file is way less complicated than keeping a
> stack of custom patches, and ensuring the same patches will be available
> on the next releases.
> 
> Yes, might not be the best scenario to go and convince your distro of
> choice to enable this or that kernel option, but then offloading this to
> kernel maintainers just because your distro doesn't do it is not the
> right thing to do.

Understood.

>> So is it a hard no for the XFS_RT automatic select ?
> 
> I'm always fine changing my mind (even if I need to knock my head on
> the desk a few times before). But unless we have a good reason to remove
> distributions the possibility to have zoned devices enabled without
> XFS_RT, in lieu of distributions that don't want to bother maintaining
> their configuration files, this is a hard no from me.
> 
> And I don't consider "changing the config file of a distribution is
> painful" as a good reason.

I understand.

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Christoph Hellwig]

On Wed, Aug 06, 2025 at 09:46:58AM +0200, Carlos Maiolino wrote:
> > +	select XFS_RT if BLK_DEV_ZONED
> 
> This looks weird to me.
> Obligating users to enable an optional feature in xfs if their
> kernel are configured with a specific block dev feature doesn't
> sound the right thing to do.
> What if the user doesn't want to use XFS RT devices even though
> BLK_DEV_ZONED is enabled, for whatever other purpose?
> 
> Forcing enabling a filesystem configuration because a specific block
> feature is enabled doesn't sound the right thing to do IMHO.

Yes.  What might be useful is to default XFS_RT to on for BLK_DEV_ZONED.
I.e.

	config XFS_RT
		...
		default BLK_DEV_ZONED
		...

That way we get a good default, but still allow full selection /
deselection.

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Carlos Maiolino]

On Mon, Aug 11, 2025 at 12:50:07PM +0200, Christoph Hellwig wrote:
> On Wed, Aug 06, 2025 at 09:46:58AM +0200, Carlos Maiolino wrote:
> > > +	select XFS_RT if BLK_DEV_ZONED
> >
> > This looks weird to me.
> > Obligating users to enable an optional feature in xfs if their
> > kernel are configured with a specific block dev feature doesn't
> > sound the right thing to do.
> > What if the user doesn't want to use XFS RT devices even though
> > BLK_DEV_ZONED is enabled, for whatever other purpose?
> >
> > Forcing enabling a filesystem configuration because a specific block
> > feature is enabled doesn't sound the right thing to do IMHO.
> 
> Yes.  What might be useful is to default XFS_RT to on for BLK_DEV_ZONED.
> I.e.
> 
> 	config XFS_RT
> 		...
> 		default BLK_DEV_ZONED
> 		...
> 
> That way we get a good default, but still allow full selection /
> deselection.

This sounds a good compromise.

Re: [PATCH] xfs: Select XFS_RT if BLK_DEV_ZONED is enabled

[Damien Le Moal]

On 8/11/25 7:56 PM, Carlos Maiolino wrote:
> On Mon, Aug 11, 2025 at 12:50:07PM +0200, Christoph Hellwig wrote:
>> On Wed, Aug 06, 2025 at 09:46:58AM +0200, Carlos Maiolino wrote:
>>>> +	select XFS_RT if BLK_DEV_ZONED
>>>
>>> This looks weird to me.
>>> Obligating users to enable an optional feature in xfs if their
>>> kernel are configured with a specific block dev feature doesn't
>>> sound the right thing to do.
>>> What if the user doesn't want to use XFS RT devices even though
>>> BLK_DEV_ZONED is enabled, for whatever other purpose?
>>>
>>> Forcing enabling a filesystem configuration because a specific block
>>> feature is enabled doesn't sound the right thing to do IMHO.
>>
>> Yes.  What might be useful is to default XFS_RT to on for BLK_DEV_ZONED.
>> I.e.
>>
>> 	config XFS_RT
>> 		...
>> 		default BLK_DEV_ZONED
>> 		...
>>
>> That way we get a good default, but still allow full selection /
>> deselection.
> 
> This sounds a good compromise.

Indeed. I'll send a patch.


-- 
Damien Le Moal
Western Digital Research