Re: [PATCH 2/3] nfsd: move change attribute generation to filesystem
From: Christoph Hellwig <hch@infradead.org>
Date: 2021-01-22 08:22:04
Also in:
linux-fsdevel
From: Christoph Hellwig <hch@infradead.org>
Date: 2021-01-22 08:22:04
Also in:
linux-fsdevel
On Thu, Jan 21, 2021 at 03:27:56PM -0500, J. Bruce Fields wrote:
quoted
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.quoted
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?