All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: statfs() / statvfs() syscall ballsup...
Date: Fri, 10 Oct 2003 15:35:53 +0100	[thread overview]
Message-ID: <20031010143553.GA28795@mail.shareable.org> (raw)
In-Reply-To: <16262.47147.943477.24070@charged.uio.no>

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

  reply	other threads:[~2003-10-10 14:36 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-09 22:16 Trond Myklebust
2003-10-09 22:26 ` Linus Torvalds
2003-10-09 23:19   ` Ulrich Drepper
2003-10-10  0:22     ` viro
2003-10-10  4:49       ` Jamie Lokier
2003-10-10  5:26         ` Trond Myklebust
2003-10-10 12:37           ` Jamie Lokier
2003-10-10 13:46             ` Trond Myklebust
2003-10-10 14:35               ` Jamie Lokier [this message]
2003-10-10 15:32                 ` Misc NFSv4 (was Re: statfs() / statvfs() syscall ballsup...) Trond Myklebust
2003-10-10 15:53                   ` Jamie Lokier
2003-10-10 16:07                     ` Trond Myklebust
2003-10-10 15:55                   ` Michael Shuey
2003-10-10 16:20                     ` Trond Myklebust
2003-10-10 16:45                     ` J. Bruce Fields
2003-10-10 14:39               ` statfs() / statvfs() syscall ballsup Jamie Lokier
2003-10-09 23:31   ` Trond Myklebust
2003-10-10 12:27   ` Joel Becker
2003-10-10 14:59     ` Linus Torvalds
2003-10-10 15:27       ` Joel Becker
2003-10-10 16:00         ` Linus Torvalds
2003-10-10 16:26           ` Joel Becker
2003-10-10 16:50             ` Linus Torvalds
2003-10-10 17:33               ` Joel Becker
2003-10-10 17:51                 ` Linus Torvalds
2003-10-10 18:13                   ` Joel Becker
2003-10-10 16:27           ` Valdis.Kletnieks
2003-10-10 16:33           ` Chris Friesen
2003-10-10 17:04             ` Linus Torvalds
2003-10-10 17:07               ` Linus Torvalds
2003-10-10 17:21                 ` Joel Becker
2003-10-10 16:01         ` Jamie Lokier
2003-10-10 16:33           ` Joel Becker
2003-10-10 16:58             ` Chris Friesen
2003-10-10 17:05               ` Trond Myklebust
2003-10-10 17:20               ` Joel Becker
2003-10-10 17:33                 ` Chris Friesen
2003-10-10 17:40                 ` Linus Torvalds
2003-10-10 17:54                   ` Trond Myklebust
2003-10-10 18:05                     ` Linus Torvalds
2003-10-10 20:40                       ` Trond Myklebust
2003-10-10 21:09                         ` Linus Torvalds
2003-10-10 22:17                           ` Trond Myklebust
2003-10-11  2:53                     ` Andrew Morton
2003-10-11  3:47                       ` Trond Myklebust
2003-10-10 18:05                   ` Joel Becker
2003-10-10 18:31                     ` Andrea Arcangeli
2003-10-10 20:33                     ` Helge Hafting
2003-10-10 20:07             ` Jamie Lokier
2003-10-12 15:31             ` Greg Stark
2003-10-12 16:13               ` Linus Torvalds
2003-10-12 22:09                 ` Greg Stark
2003-10-13  8:45                   ` Helge Hafting
2003-10-15 13:25                     ` Ingo Oeser
2003-10-15 15:03                       ` Greg Stark
2003-10-15 18:37                         ` Helge Hafting
2003-10-16 10:29                         ` Ingo Oeser
2003-10-16 14:02                           ` Greg Stark
2003-10-21 11:47                             ` Ingo Oeser
2003-10-10 18:20           ` Andrea Arcangeli
2003-10-10 18:36             ` Linus Torvalds
2003-10-10 19:03               ` Andrea Arcangeli
2003-10-09 23:16 ` Andreas Dilger
2003-10-09 23:24   ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031010143553.GA28795@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    --subject='Re: statfs() / statvfs() syscall ballsup...' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.