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 13:37:32 +0100	[thread overview]
Message-ID: <20031010123732.GA28224@mail.shareable.org> (raw)
In-Reply-To: <16262.17185.757790.524584@charged.uio.no>

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.


  reply	other threads:[~2003-10-10 12:37 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 [this message]
2003-10-10 13:46             ` Trond Myklebust
2003-10-10 14:35               ` Jamie Lokier
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=20031010123732.GA28224@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.