changing semantics of the va_filerev (code review)

[Christoph Hellwig]

On Mon, Apr 13, 2009 at 11:13:33AM -0400, Rick Macklem wrote:
> If a file system can't support it correctly, faking it with something
> like modify time is about all you can do. Since Change is supposed to
> change on every file modification, this fails when multiple changes
> occur within the same tod clock time or the clock gets reset backwards,
> as you noted below. (Linux uses a modify time with a 1sec clock
> resolution for Change, which isn't correct and the Linux nfs server
> folks know that. Since this breaks the AIX nfsv4 client, the AIX folks
> tend to remind them:-)

Linux uses whatever granularity the underlying filesystems support.
For a lot of all designs that may be 1 second, for most recent
filesystems it's better.

> Yep, that's why ctime/mtime aren't sufficient.
> If a read/write file system doesn't have support for it, all you
> can do is fake it and hope the client works ok. I suspect the Linux
> folks will eventually start to add support for it to ext3fs etc, because
> of the above, but who knows. It seems that FreeBSD mostly uses FFS and
> ZFS (which should have support for it, since the Solaris folks are into
> NFSv4?), so at least we should be able to make those work correctly.

Linux already has the changecount in ext4 but the NFS server doesn't yet
use it.  Also it's beeing implemented for XFS and others.