All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: root@chaos.analogic.com
Cc: "martin.knoblauch " <"martin.knoblauch "@mscsoftware.com>,
	Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: nfs_statfs: statfs error = 116
Date: 13 Nov 2003 10:27:47 -0500	[thread overview]
Message-ID: <shssmks70gc.fsf@charged.uio.no> (raw)
In-Reply-To: <Pine.LNX.4.53.0311130927280.30784@chaos>

>>>>> " " == Richard B Johnson <root@chaos.analogic.com> writes:

     > ESTALE happens when a mounted file-system is on a server that
     > went down or re-booted. The file-handles are then "stale".

Sort of. It means that the server is unable to find the file that
corresponds to the filehandle that the client sent it. If the server
strictly follows the NFS specs, then this is only supposed to happen
if somebody else has deleted the file (and this is why designing a
scheme for generating filehandles is such a difficult job).

Some broken servers do, however, "lose" the file in other interesting
and unpredictable ways.

     > ERESTARTSYS is the error returned by a server that has
     > re-booted that is supposed to tell the client-side software to
     > get a new file-handle because of an attempt to access with a
     > stale file-handle. When getting this error, the client should
     > have reopened the file(s) to obtain a new handle.

ERESTARTSYS actually just means that a signal was received while
inside a system call. If this results in a interruption of that
syscall, the kernel is supposed to translate ERESTARTSYS into the user
error EINTR.

Userland should therefore never have to handle ERESTARTSYS errors.

Cheers,
  Trond

  parent reply	other threads:[~2003-11-13 15:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-13 14:15 nfs_statfs: statfs error = 116 martin.knoblauch 
2003-11-13 14:39 ` Richard B. Johnson
2003-11-13 14:52   ` Martin.Knoblauch
2003-11-13 20:26     ` Jesse Pollard
2003-11-13 20:34       ` Trond Myklebust
2003-11-14  8:43         ` Martin.Knoblauch
2003-11-14 13:49           ` Trond Myklebust
2003-11-14 14:22             ` Martin.Knoblauch
2003-11-13 15:27   ` Trond Myklebust [this message]
2003-11-13 16:00     ` Richard B. Johnson
2003-11-13 17:03       ` Trond Myklebust
  -- strict thread matches above, loose matches on Subject: below --
2003-09-18  9:56 Marc Schmitt
2003-09-18 13:49 ` Steve Dickson
2003-09-18 19:24   ` Bernd Schubert
2003-09-18 19:31     ` Marc Schmitt
2003-09-18 19:49       ` Bernd Schubert
2003-11-14 14:57         ` Marc Schmitt
2003-09-18 19:26   ` Marc Schmitt
2003-09-19  0:22     ` Neil Brown
2003-09-19  9:27       ` Marc Schmitt
2003-09-21 13:38   ` Marc Schmitt

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=shssmks70gc.fsf@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc="martin.knoblauch "@mscsoftware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /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 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.