public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: David Fries <dfries@umr.edu>,
	linux-kernel@vger.kernel.org,
	Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: Stale NFS handles on 2.4.2
Date: 28 Feb 2001 13:02:31 +0100	[thread overview]
Message-ID: <shsd7c3817s.fsf@charged.uio.no> (raw)
In-Reply-To: <20010214002750.B11906@unthought.net> <20010224141855.B12988@d-131-151-189-65.dynamic.umr.edu> <15000.39826.947692.141119@notabene.cse.unsw.edu.au> <20010224235342.D483@d-131-151-189-65.dynamic.umr.edu> <15000.53110.664338.230709@notabene.cse.unsw.edu.au> <20010225131013.E483@d-131-151-189-65.dynamic.umr.edu> <15004.16978.439300.108625@notabene.cse.unsw.edu.au>
In-Reply-To: Neil Brown's message of "Wed, 28 Feb 2001 11:12:02 +1100 (EST)"

>>>>> " " == Neil Brown <neilb@cse.unsw.edu.au> writes:

     > So... you can access things under /home/david, but you cannot
     > access /home/david itself?  So, supposing that "fred" were some
     > file that you happen to know is in /home/david, then

     >     ls /home/david fails with ESTALE and does not cause
     > 			       any traffic to the server and

This is normal. Once an inode gets flagged as being stale, then it
remains stale. After all it would be a bug too if a filehandle were
stale one moment, and then not the next.

The question here is therefore really why did the server tell us that
the filehandle was stale in the first place.

Cheers,
   Trond

  reply	other threads:[~2001-02-28 12:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-13 23:27 Stale NFS handles on 2.4.1 Jakob Østergaard
2001-02-13 23:31 ` Alan Cox
2001-02-13 23:43   ` Jakob Østergaard
2001-02-14  8:35   ` Rogier Wolff
2001-02-14  0:02 ` Trond Myklebust
2001-02-24 20:18 ` Stale NFS handles on 2.4.2 David Fries
2001-02-25  5:43   ` Neil Brown
2001-02-25  5:53     ` David Fries
2001-02-25  9:25       ` Neil Brown
2001-02-25 19:10         ` David Fries
2001-02-28  0:12           ` Neil Brown
2001-02-28 12:02             ` Trond Myklebust [this message]
2001-02-28 22:15               ` Neil Brown
2001-03-01  1:13                 ` Trond Myklebust
     [not found]                   ` <20010228211808.C24668@d-131-151-189-65.dynamic.umr.edu>
2001-03-01  9:07                     ` Trond Myklebust
     [not found]                       ` <s5gwva9simp.fsf@egghead.curl.com>
2001-03-01 14:13                         ` Stale NFS handles on 2.4.2^H^H^H^H^H2.2.19 Trond Myklebust
2001-02-25 14:00   ` Stale NFS handles on 2.4.2 Trond Myklebust
2001-02-26  9:54     ` Lennert Buytenhek
2001-02-26 15:56       ` David Fries

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=shsd7c3817s.fsf@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=dfries@umr.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    /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