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
