mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: ptb@it.uc3m.es
Cc: Mike Black <mblack@csihq.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.8 NFS Problems
Date: Fri, 7 Sep 2001 14:27:06 +0200	[thread overview]
Message-ID: <15256.48410.491658.624569@charged.uio.no> (raw)
In-Reply-To: <200109071206.OAA24577@nbd.it.uc3m.es>
In-Reply-To: <shsae07md9d.fsf@charged.uio.no> <200109071206.OAA24577@nbd.it.uc3m.es>

>>>>> " " == Peter T Breuer <ptb@it.uc3m.es> writes:

     > It would be nice if nfs could do the a remount automatically
     > when the nfs handle it has goes stale an dit discovers it.  Is
     > that part of v3 nfs or not?

The exact wording in RFC1813 is

   NFS3ERR_STALE
       Invalid file handle. The file handle given in the
       arguments was invalid. The file referred to by that file
       handle no longer exists or access to it has been
       revoked.

The problem is with the 'access to it has been revoked'. It says
nothing about whether or not that is permanent, hence you have to be
very careful about applying this concept to the mount point.

In any case, remounting automatically is a very bad idea unless you do
it cleanly (i.e. kill all existing processes, unmount the disk, and
then start afresh). If you just do it transparently and don't clean
out the (d|i)caches, you will see some pretty odd things happening if
filehandles on the new disk don't match the filehandles on the old
disk.
This is BTW the reason why unfsd is badly broken wrt. CDROMS.

     > But soft mounts at least break nicely and automatically.  And
     > since failures are inevitable, I prefer them.

     > Come to think of it, why not have an option that does a
     > hard,intr but sends a ^C automatically to all referents when a
     > stale handle is detected.

See above.

Cheers,
   Trond

  parent reply	other threads:[~2001-09-07 12:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-05 11:56 Mike Black
2001-09-07 11:49 ` Trond Myklebust
2001-09-07 12:05   ` Peter T. Breuer
2001-09-07 12:27   ` Trond Myklebust [this message]
2001-09-07 12:36   ` Trond Myklebust
2001-09-07 13:13   ` Mike Black
2001-09-07 14:42   ` Trond Myklebust
2001-09-07 15:46     ` Mike Black
2001-09-08 10:53     ` Trond Myklebust
2001-09-08 11:53       ` Mike Black
2001-12-20  9:44 Steffen Persvold
2001-12-20 11:10 ` Trond Myklebust
2001-12-20 14:40   ` Steffen Persvold
2001-12-20 20:27   ` Trond Myklebust

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=15256.48410.491658.624569@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mblack@csihq.com \
    --cc=ptb@it.uc3m.es \
    /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

all inboxes | Powered by JetHome®