Messages in this thread | | | Date | Fri, 10 Oct 2003 13:37:32 +0100 | From | Jamie Lokier <> | Subject | Re: statfs() / statvfs() syscall ballsup... |
| |
Trond Myklebust wrote: > > - are dnotify / lease / lock reliable indicators on this filesystem? > > (i.e. dnotify is reliable on all local filesystems, but > > not over any of the remote ones AFAIK). > > Belongs in fcntl()... Just return ENOLCK if someone tries to set a > lease or a directory notification on an NFS file...
Yes, that would make sense. 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.
> > - is stat() reliable (local filesystems and many remote) or > > potentially out of date without open/close (NFS due to > > attribute cacheing) > > There are many possible cache consistency models out there. Consider > for instance AFS connected/disconnected modes, NFSv4 delegations or > CIFS shares. How are you going to distinguish between them all and > how do you propose that applications make use of this information?
The difference is that NFSv3 can return _stale_ data, while local _cannot_. I call stat(), and the information is up to date.
I don't care about the cache semantics at all; what I care about is whether a returned stat() result may be stale.
Why? This is the difference between "make" generating correct data, and "make" generating incorrect data.[1]
The caching model isn't the issue. That's the filesystem's problem. I just want a way to get up to date data in my application.
My motivation isn't actually "make" although that's important; generally, I need to know how to verify my in-application cache of a file. (Think fontconfig, ccache etc). I use dnotify for similar purposes, when it's local. (dnotify is much faster than many stats for a complex cache dependency).
Currently, I use statfs() and read /proc/mounts to determine whether the filesystem is a known type or mounted on a block device, to decide whether stat() and/or dnotify are reliable. 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]
-- Jamie
[1] I have built programs, including kernels, which crashed due to timestamps not appearing on a different computer after changing code so make didn't compile everything.
[2] I have lost code I was editing due to saving it and then a different computer updating the file by reading a stale version, modifying it and writing it.
- 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/
| |