On Fri, Jul 09, 2021 at 07:25:09AM +0100, Christoph Hellwig wrote: > On Thu, Jul 08, 2021 at 09:12:09PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > Commit 603f000b15f2 changed xfs_ioctl_setattr_check_extsize to reject an > > attempt to set an EXTSZINHERIT extent size hint on a directory with > > RTINHERIT set if the hint isn't a multiple of the realtime extent size. > > However, I have recently discovered that it is possible to change the > > realtime extent size when adding a rt device to a filesystem, which > > means that the existence of directories with misaligned inherited hints > > is not an accident. > > > > As a result, it's possible that someone could have set a valid hint and > > added an rt volume with a different rt extent size, which invalidates > > the ondisk hints. After such a sequence, FSGETXATTR will report a > > misaligned hint, which FSSETXATTR will trip over, causing confusion if > > the user was doing the usual GET/SET sequence to change some other > > attribute. Change xfs_fill_fsxattr to omit the hint if it isn't aligned > > properly. > > Looks sensible, but maybe we need a pr_info_ratelimited to inform > the user of this case? Why? Now that I've established that the system administrator is and always has been allowed to invalidate the extent size hints when realtime volumes are in play, I don't think we need to spam the kernel log about the admin's strange choices. The only reason I put that xfs_info_once thing in 603f00 is because I mistakenly thought that the only way we could end up with a fs like that was due to gaps in user input sanitization, i.e. fs isn't supposed to be weird, but it is anyway. --D
