Re: statfs() / statvfs() syscall ballsup...

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Jamie Lokier <jamie@shareable.org> writes:

     > Trond Myklebust wrote:
    >> Belongs in fcntl()... Just return ENOLCK if someone tries to
    >> set a lease or a directory notification on an NFS file...

     > It should be a filesystem hook, so that even remote filesystems
     > like SMB can implement it, although it must be understood that
     > remote notification has different ordering properties than
     > local.

Sure. We might even try actually implementing leases on NFSv4 for
delegated files.

     > I don't care about the cache semantics at all; what I care
     > about is whether a returned stat() result may be stale.

Note that this too may be a per-file property. Under NFSv4 I can
guarantee you that stat() results are correct in the case where I have
a delegation. Otherwise, you are indeed subject to inherent races.
"noac" cannot entirely resolve such races, but it sounds as if it
could in the particular cases you describe.

     > This is not ideal.  In particular, I don't know of any way to
     > _guarantee_ that I have the latest file contents from remote
     > filesystems short of F_SETLK, which way too heavy.[2]

Err... open() should normally suffice to do that...

Unless you are simultaneously writing to the file on a remote system,
in which case you really need mandatory locking rather than NFSv2/v3's
weaker advisory model. Or possibly something like CIFS/SMB's open
"share" model (which can also be implemented in NFSv4).



...so I would argue that the caching models both can and do make a
difference to your example cases (contrary to what you assert).

Cheers,
  Trond