mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg Banks <gnb@melbourne.sgi.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: "Sven Köhler" <skoehler@upb.de>,
	linux-kernel@vger.kernel.org,
	"Linux NFS Mailing List" <nfs@lists.sourceforge.net>
Subject: Re: [NFS] Re: why do i get "Stale NFS file handle" for hours?
Date: Tue, 07 Sep 2004 10:55:32 +1000	[thread overview]
Message-ID: <1094518532.20243.50.camel@hole.melbourne.sgi.com> (raw)
In-Reply-To: <1094353267.13791.156.camel@lade.trondhjem.org>

On Sun, 2004-09-05 at 13:01, Trond Myklebust wrote:
> When your server fails to work as per spec, then it is said to be
> "broken" no matter what kernel/nfs-utils combination you are using.
> The spec is that reboots are not supposed to clobber filehandles.
> 
> So, there are 3 possibilities:
> 
>  1) You are exporting a non-supported filesystem, (e.g. FAT). See the
> FAQ on http://nfs.sourceforge.org.
>  2) A bug in your initscripts is causing the table of exports to be
> clobbered. Running "exportfs" in legacy 2.4 mode (without having the
> nfsd filesystem mounted on /proc/fs/nfsd) appears to be broken for me at
> least...
>  3) There is some other bug in knfsd that nobody else appears to be
> seeing.
> 

4) You're exporting a filesystem mounted on a block device whose
   device minor number is dynamic and has changed at the last reboot,
   e.g. loopback mounts or SCSI.
5) The mapping of minor numbers is stable but you physically re-arranged
   the disks or SCSI cards and changed /etc/fstab correspondingly.

Before you say any more, yes this is broken and fixing it properly is
Hard.  This is why have the fsid export option.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.



      parent reply	other threads:[~2004-09-07  0:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-05  1:06 Sven Köhler
2004-09-05  1:39 ` Trond Myklebust
2004-09-05  1:51   ` Sven Köhler
2004-09-05  2:02     ` Trond Myklebust
2004-09-05  2:23       ` Sven Köhler
2004-09-05  3:01         ` Trond Myklebust
2004-09-05  8:17           ` Tim Connors
2004-09-05  8:59             ` Florian Weimer
2004-09-05  9:02               ` Tim Connors
2004-09-05 16:20             ` Mike Jagdis
2004-09-06  1:32               ` Tim Connors
2004-09-05 13:18           ` Sven Köhler
2004-09-05 20:10             ` Trond Myklebust
2004-09-06  7:47               ` Kalin KOZHUHAROV
2004-09-06  9:57           ` David Woodhouse
2004-09-06 15:59             ` Trond Myklebust
2004-09-07  0:55           ` Greg Banks [this message]

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=1094518532.20243.50.camel@hole.melbourne.sgi.com \
    --to=gnb@melbourne.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfs@lists.sourceforge.net \
    --cc=skoehler@upb.de \
    --cc=trond.myklebust@fys.uio.no \
    /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®