On Thu, Jan 21, 2021 at 03:27:56PM -0500, J. Bruce Fields wrote: > > Another indirect call just to fetch the change attribute (which happens > > a lot IIRC) does not seem very optimal to me. > > In the next patch we're removing an fh_getattr (vfs_getattr) in the case > we call the new op, so that's typically a net decrease in indirect > calls. > > Though maybe we could use a flag here and do without either. > > > And the fact that we need three duplicate implementations also is not > > very nice. > > Ext4 and xfs are identical, btrfs is a little different since it doesn't > consult I_VERSION. (And then there's nfs, which uses the origin > server's i_version if it can.) I'd much prefer to just keep consulting the I_VERSION flag and only add the new op as an override for the NFS export. > > I also have a vague idea that some filesystem-specific improvements > might be possible. (E.g., if a filesystem had some kind of boot count > in the superblock, maybe that would be a better way to prevent the > change attribute from going backwards on reboot than the thing > generic_fetch_iversion is currently doing with ctime. But I have no > concrete plan there, maybe I'm dreaming.) Even without the ctime i_version never goes backward, what is the problem here?
