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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
>> ---
>>  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




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux