Re: [PATCH] xfs: fix i_version handling in xfs

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

 



On Wed, 17 Aug 2022, Dave Chinner wrote:
> 
> In XFS, we've defined the on-disk i_version field to mean
> "increments with any persistent inode data or metadata change",
> regardless of what the high level applications that use i_version
> might actually require.
> 
> That some network filesystem might only need a subset of the
> metadata to be covered by i_version is largely irrelevant - if we
> don't cover every persistent inode metadata change with i_version,
> then applications that *need* stuff like atime change notification
> can't be supported.

So what you are saying is that the i_version provided by XFS does not
match the changeid semantics required by NFSv4.  Fair enough.  I guess
we shouldn't use the one to implement the other then.

Maybe we should just go back to using ctime.  ctime is *exactly* what
NFSv4 wants, as long as its granularity is sufficient to catch every
single change.  Presumably XFS doesn't try to ensure this.  How hard
would it be to get any ctime update to add at least one nanosecond?
This would be enabled by a mount option, or possibly be a direct request
from nfsd.

<rant>NFSv4 changeid is really one of the more horrible parts of the
design</rant>

NeilBrown



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux