Messages in this thread | | | Date | Fri, 10 Oct 2003 09:46:19 -0400 | Subject | Re: statfs() / statvfs() syscall ballsup... | From | Trond Myklebust <> |
| |
>>>>> " " == 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |