public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Marcus Sundberg <marcus@cendio.se>
Cc: linux-kernel@vger.kernel.org
Subject: Re: nfs is stupid ("getfh failed")
Date: 12 Sep 2001 13:13:12 +0200	[thread overview]
Message-ID: <shsvgiohdbr.fsf@charged.uio.no> (raw)
In-Reply-To: <002b01c136e1$3bb36a80$81d4870a@cartman> <15261.47176.73283.841982@notabene.cse.unsw.edu.au> <vebskgpu32.fsf@inigo.sthlm.cendio.se>
In-Reply-To: Marcus Sundberg's message of "12 Sep 2001 12:44:01 +0200"

>>>>> " " == Marcus Sundberg <marcus@cendio.se> writes:

     > neilb@cse.unsw.edu.au (Neil Brown) writes:
    >> On September 10, marcus@cendio.se wrote:
    >> > cachefs sucks. It doesn't seem to cache stat(2) information.
    >> > Doing ls -F in a ~100-entries directory takes several seconds
    >> > over a link with 50ms round-trip time.
    >>
    >> Well, I said "concept" not "implementation", but I suspect that
    >> Solaris cachefs does cache stat information.  Maybe you just
    >> need to increase the timeouts for the attribute cache.

     > Considering that I did several ls'es on the order of
     > milliseconds apart I doubt that would help...

The NFS close-to-open cache consistency requirement forces them to
compare the attribute cache to the server every time someone does a
call to open(). This is true whether or not one uses cachefs.

After the file has actually been opened, you can call fstat() as many
times as you like. The cached attributes to be used, and they will
then be checked on the server only after the cache times out.

Cheers,
   Trond

  reply	other threads:[~2001-09-12 11:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-06 14:35 nfs is stupid ("getfh failed") Michael Rothwell
2001-09-07  1:59 ` Jamie Lokier
2001-09-11  7:06   ` Neil Brown
2001-09-11  9:55     ` Jamie Lokier
2001-09-11 10:01       ` Neil Brown
2001-09-07 11:47 ` Neil Brown
2001-09-07 12:58   ` Michael Rothwell
2001-09-07 14:17     ` Tim Walberg
2001-09-08  0:02     ` Johan Kullstam
2001-09-08 13:38       ` Alan Cox
2001-09-09 10:05         ` Henning P. Schmiedehausen
2001-09-09 16:44           ` Michael Rothwell
2001-09-10  6:55     ` Neil Brown
2001-09-10  9:32       ` Marcus Sundberg
2001-09-11  7:07         ` Neil Brown
2001-09-12 10:44           ` Marcus Sundberg
2001-09-12 11:13             ` Trond Myklebust [this message]
2001-09-12 12:22             ` Neil Brown

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=shsvgiohdbr.fsf@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcus@cendio.se \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox