Re: [PATCH 2/3] nfsd: move change attribute generation to filesystem

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

 



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?



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux