lkml.org 
[lkml]   [2003]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.093 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site