Re: statfs() / statvfs() syscall ballsup...
From: Trond Myklebust
Date: Fri Oct 10 2003 - 08:47:04 EST
>>>>> " " == Jamie Lokier <jamie@xxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/