Messages in this thread | | | Date | Fri, 10 Oct 2003 15:35:53 +0100 | From | Jamie Lokier <> | Subject | Re: statfs() / statvfs() syscall ballsup... |
| |
Trond Myklebust wrote: > Sure. We might even try actually implementing leases on NFSv4 for > delegated files.
That would be nice. (Aside: Can NFSv4 do anything like dnotify, or am I restricted to, in effect, keeping many files open to detect changes in any of them?)
Generally NFSv4 sounds like the way to go. Should I be recommending it to all my friends yet, is the implementation ready for that?
> > 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.
You're right, in the cases I describe "noac" is fine.
I don't like having to ship an FAQ with a program which explains that the program is theoretically fine, users should simply mount their home directory with "noac", and tough if that's not within their administrative power.
I'd rather make the program work correctly with the default mount options, and maybe have an entry in the FAQ saying that "noac" may improve performance but is not required for correct behaviour.
Unfortunately that means ugly knowledge of filesystem specifics and /proc/mount parsing - or significantly lower performance on local filesystems, which largely negates the purpose of the program. (It is very much about caching things derived from file contents).
> > 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...
Server = RH linux-2.4.20-18.9. Client = 2.6.0-test6. I have done this in the last few days:
[on client] editing file in emacs, save-buffer [on server] diff -ur mumble commands >> file (and wait until command prompt returns) [on client] in emacs, find-alternate-file which discards the current buffer and opens & reads the file from fs. [on client] edit some more, save file, post to l-k etc. [meta] notice that the diff wasn't appended to the file
Emacs didn't see the appended data. (The reason I did the diff command on the server is that it's a lot faster - a tree's worth of stat calls is slow over PCMCIA ethernet).
> ...so I would argue that the caching models both can and do make a > difference to your example cases (contrary to what you assert).
Of course they make a difference when there is no call to say "just do X and hide the implementation details from me". What I'd like is an abstraction so I don't observe a difference, or at least a systematic way of working around them at application level.
In the same way I expect CPUs to abstract away the (sometimes very) complex memory caching models, and present something simple to the program code.
-- Jamie - 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/
| |