Stale NFS handles on 2.4.1

Stale NFS handles on 2.4.1

[Jakob Østergaard]

Hi !

I'm running a compilation cluster with various machines now
on 2.4.1 all mounting the same home filesystem over NFS from
the central NFS server.

All machines are 2.4.1 using NFSv3, some SMP some UP.

NFS server is a dual running an SMP kernel

The NFS clients are getting
 "Stale NFS handle"
messages every once in a while which will make a "touch somefile.o"
fail.

It's quite annoying and I didn't see it on 2.2 even after the NFS
patches were integrated.

What happens is that one machine will finish compiling, and another
machine will immediately thereafter do a "touch some_output.o". This
"touch" sometimes fails with a stale handle message.

Is this a  known problem or should I submit more info ?  If so,
what info ?

(no nothing is overclocked, yes I'm using RedHat 7 kgcc)

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: Stale NFS handles on 2.4.1

[Alan Cox]

> The NFS clients are getting
>  "Stale NFS handle"
> messages every once in a while which will make a "touch somefile.o"
> fail.

If they have the previous .o handle cached and it was removed on another
client thats quite reasonable behaviour. NFS isnt coherent

> It's quite annoying and I didn't see it on 2.2 even after the NFS
> patches were integrated.

I wonder if its because 2.4 runs faster and caches better 8). You can
tune the attribute cache times that may help. Are we talking 30 second
intervals here or stuff being cached for far too long (which would imply a bug)

Re: Stale NFS handles on 2.4.1

[Jakob Østergaard]

On Tue, Feb 13, 2001 at 11:31:50PM +0000, Alan Cox wrote:
> > The NFS clients are getting
> >  "Stale NFS handle"
> > messages every once in a while which will make a "touch somefile.o"
> > fail.
> 
> If they have the previous .o handle cached and it was removed on another
> client thats quite reasonable behaviour. NFS isnt coherent

So a solution would be to
 <local node>  rm -f output.o
 <remote node> g++ .... -o output.o
 <local node>  touch output.o

I do the touch in the first place because a subsequent link job on
another remote node used to fail if I didn't.   NFS caching magic I guess...

> 
> > It's quite annoying and I didn't see it on 2.2 even after the NFS
> > patches were integrated.
> 
> I wonder if its because 2.4 runs faster and caches better 8). You can
> tune the attribute cache times that may help. Are we talking 30 second
> intervals here or stuff being cached for far too long (which would imply a bug)

It runs faster indeed, and it makes the work more fun and makes the
internet go faster !   (uhhh...  or maybe the internet speedup is because
of the Intel CPUs - I forgot...)

Usually how a compile goes is:

a make -j10 spawns concurrent compile jobs. Each job consists of
  "spawn on remote node"  g++ ... -o somefile.o
  "on local node"  touch somefile.o

After a truckload of .o files have been generated, it will start
up link jobs, on other remote nodes.  I haven't tried this without
the touch trick for a long time.

Each g++ job takes from a few seconds to several minutes depending
on the file and optimization options etc.  I think I mainly see this
with the fast jobs...  Most .o files are ~1-4 MB and I have about 200
of them.

~200 compilers and ~12 linkers take about 4-5 minutes to complete on
the cluster of three dual machines and two-three single cpus.  Producing
about 1.5G of object code in total  (yes C++ symbols are HUGE).

So, the touch is _immediately_ after a compile completion.  But the
.o file has not been in use on any other machine than the one running
the compiler for hours or at least many minutes (a different compile).

I'll try this without the touch trick and see how things fare...

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: Stale NFS handles on 2.4.1

[Rogier Wolff]

Alan Cox wrote:
> > The NFS clients are getting
> >  "Stale NFS handle"
> > messages every once in a while which will make a "touch somefile.o"
> > fail.
> 
> If they have the previous .o handle cached and it was removed on another
> client thats quite reasonable behaviour. NFS isnt coherent

As reported before, I see simliar stuff on an 2.2. SMP NFS client, and
an 2.2. NFS server.

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: Stale NFS handles on 2.4.1

[Trond Myklebust]

>>>>> " " == stergaard  <Jakob> writes:

     > What happens is that one machine will finish compiling, and
     > another machine will immediately thereafter do a "touch
     > some_output.o". This "touch" sometimes fails with a stale
     > handle message.

Does the appended patch change anything?

Cheers,
  Trond

--- linux-2.4.1/fs/nfs/inode.c.orig	Tue Dec 12 02:46:04 2000
+++ linux-2.4.1/fs/nfs/inode.c	Wed Feb 14 01:00:33 2001
@@ -100,6 +100,7 @@
 	inode->i_rdev = 0;
 	NFS_FILEID(inode) = 0;
 	NFS_FSID(inode) = 0;
+	NFS_FLAGS(inode) = 0;
 	INIT_LIST_HEAD(&inode->u.nfs_i.read);
 	INIT_LIST_HEAD(&inode->u.nfs_i.dirty);
 	INIT_LIST_HEAD(&inode->u.nfs_i.commit);

Re: Stale NFS handles on 2.4.2

[David Fries]

I have my home directory mounted on one computer from another.  I
rebooted the server and now the client is saying Stale NFS file handle
anytime something goes to read my home directory.  It has been this  
way for about a day.  Shouldn't any caches expire by now?

Both server and client are running 2.4.2.

I'ved tried `mount /home -o remount`, and reading lots of other
directories to flush out that entry if it was in cache without any
results.

I was hopping to avoid unmounting, as I would have to shut about
everything down to do that.

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+

Re: Stale NFS handles on 2.4.2

[Neil Brown]

On Saturday February 24, dfries@umr.edu wrote:
> I have my home directory mounted on one computer from another.  I
> rebooted the server and now the client is saying Stale NFS file handle
> anytime something goes to read my home directory.  It has been this  
> way for about a day.  Shouldn't any caches expire by now?

It isn't that a cache needs to expire.  It sounds like it is a cache
that needs to be filled.

The kernel keeps a cache of ip addresses that are allowed access to
particular filesystems.  This is visible through /proc/fs/nfs/exports.
It is filled at reboot by "exportfs -a" or "exportfs -r" which gets
information from /etc/exports and /var/lib/nfs/rmtab.

So check that /etc/exports contains the right info.
Check that /var/lib/nfs/rmtab lists the filesystems and clients that
you expect to have access, and then run "exportfs -av"

NeilBrown


> 
> Both server and client are running 2.4.2.
> 
> I'ved tried `mount /home -o remount`, and reading lots of other
> directories to flush out that entry if it was in cache without any
> results.
> 
> I was hopping to avoid unmounting, as I would have to shut about
> everything down to do that.
> 
> -- 
> 		+---------------------------------+
> 		|      David Fries                |
> 		|      dfries@umr.edu             |
> 		+---------------------------------+
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Stale NFS handles on 2.4.2

[David Fries]

On Sun, Feb 25, 2001 at 04:43:46PM +1100, Neil Brown wrote:
> On Saturday February 24, dfries@umr.edu wrote:
> > I have my home directory mounted on one computer from another.  I
> > rebooted the server and now the client is saying Stale NFS file handle
> > anytime something goes to read my home directory.  It has been this  
> > way for about a day.  Shouldn't any caches expire by now?
> 
> It isn't that a cache needs to expire.  It sounds like it is a cache
> that needs to be filled.
> 
> The kernel keeps a cache of ip addresses that are allowed access to
> particular filesystems.  This is visible through /proc/fs/nfs/exports.
> It is filled at reboot by "exportfs -a" or "exportfs -r" which gets
> information from /etc/exports and /var/lib/nfs/rmtab.
> 
> So check that /etc/exports contains the right info.
> Check that /var/lib/nfs/rmtab lists the filesystems and clients that
> you expect to have access, and then run "exportfs -av"

checked, verified, re-exported, still Stale NFS file handle on client.
I also used tcpdump on server and when I do ls on my home directory
(this is where I see the Stale NFS message), it does not generate any
network traffic.  It can't be the server if the client isn't asking
for it.

> > Both server and client are running 2.4.2.
> > 
> > I'ved tried `mount /home -o remount`, and reading lots of other
> > directories to flush out that entry if it was in cache without any
> > results.
> > 
> > I was hopping to avoid unmounting, as I would have to shut about
> > everything down to do that.

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+

Re: Stale NFS handles on 2.4.2

[Neil Brown]

On Saturday February 24, dfries@umr.edu wrote:
[problem summary: After restarting knfsd server on 2.4.2, client
                  reports Stale NFS file handle]

> On Sun, Feb 25, 2001 at 04:43:46PM +1100, Neil Brown wrote:
> > So check that /etc/exports contains the right info.
> > Check that /var/lib/nfs/rmtab lists the filesystems and clients that
> > you expect to have access, and then run "exportfs -av"
> 
> checked, verified, re-exported, still Stale NFS file handle on client.
> I also used tcpdump on server and when I do ls on my home directory
> (this is where I see the Stale NFS message), it does not generate any
> network traffic.  It can't be the server if the client isn't asking
> for it.

Verrry odd.  I can see why you were suspecting a cache.
I'm probably going to have to palm this off to Trond, the NFS client
maintainer (are you listening Trond?) but could please confirm that
from the client you can:

 1/ ping server
 2/ rpcinfo -p server
 3/ showmount -e server
 4/ mount server:/exported/filesys /some/other/mount/point

If all of these work, them I am mistified.  If one of these fails,
then that might point the way to further investigation.

NeilBrown

> 
> > > Both server and client are running 2.4.2.
> > > 
> > > I'ved tried `mount /home -o remount`, and reading lots of other
> > > directories to flush out that entry if it was in cache without any
> > > results.
> > > 
> > > I was hopping to avoid unmounting, as I would have to shut about
> > > everything down to do that.
> 
> -- 
> 		+---------------------------------+
> 		|      David Fries                |
> 		|      dfries@umr.edu             |
> 		+---------------------------------+

Re: Stale NFS handles on 2.4.2

[David Fries]

On Sun, Feb 25, 2001 at 08:25:10PM +1100, Neil Brown wrote:
> On Saturday February 24, dfries@umr.edu wrote:
> Verrry odd.  I can see why you were suspecting a cache.
> I'm probably going to have to palm this off to Trond, the NFS client
> maintainer (are you listening Trond?) but could please confirm that
> from the client you can:
> 
>  1/ ping server
>  2/ rpcinfo -p server
>  3/ showmount -e server
>  4/ mount server:/exported/filesys /some/other/mount/point
> 
> If all of these work, them I am mistified.  If one of these fails,
> then that might point the way to further investigation.

I have server:/home mounted on /home, the directory /home/david is the
mount file/directory on that mount that has a stale handle, everything
else on that mount point works including accessing any file under
/home/david.

I mounted it on a different directory and the new mount was fine, and
the problem directory on the new mount was fine, but the problem
directory on the old mount was still stale.

Yes it is a ext2 file system being exported.  It is using the kernel
nfs server.

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+

Re: Stale NFS handles on 2.4.2

[Neil Brown]

On Sunday February 25, dfries@umr.edu wrote:
> On Sun, Feb 25, 2001 at 08:25:10PM +1100, Neil Brown wrote:
> > On Saturday February 24, dfries@umr.edu wrote:
> > Verrry odd.  I can see why you were suspecting a cache.
> > I'm probably going to have to palm this off to Trond, the NFS client
> > maintainer (are you listening Trond?) but could please confirm that
> > from the client you can:
> > 
> >  1/ ping server
> >  2/ rpcinfo -p server
> >  3/ showmount -e server
> >  4/ mount server:/exported/filesys /some/other/mount/point
> > 
> > If all of these work, them I am mistified.  If one of these fails,
> > then that might point the way to further investigation.
> 
> I have server:/home mounted on /home, the directory /home/david is the
> mount file/directory on that mount that has a stale handle, everything
> else on that mount point works including accessing any file under
> /home/david.

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
    ls -l /home/david/fred     succeeds.

Is that right?

Could you try:
  echo 255 > /proc/sys/sunrpc/nfs_debug 

and then do the "ls /home/david" and see what gets put in 
/var/log/messages (or kern_log or syslog or where such things go).

NeilBrown

Re: Stale NFS handles on 2.4.2

[Trond Myklebust]

>>>>> " " == 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

Re: Stale NFS handles on 2.4.2

[Neil Brown]

On  February 28, trond.myklebust@fys.uio.no wrote:
> >>>>> " " == 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.
> 
I don't think that is necessarily a bug.
If I mis-configured the server to deny access to a particular client,
the client would start getting NFSERR_STALE responses.  I notice the
problem and reconfigure the server and I would expect the ESTALE
errors to go away.  But apparently they don't.   Or atleast they don't
as long as the inode stays in the cache.  Once it gets flushed from
the cache, a lookup will cause everything to work again.
But if an object below a "STALE" directory is being held open, the
inode will never get flushed and so the inode stays stale.

What is really odd about this situation is that whenever David tries
to access his home directory (/home/david) nfs_lookup_revalidate will
be called which will (if the cache isn't fresh enough) do a "lookup"
which returns the filehandle and attributes of /home/david.  This
should be enough to convince the client that the filehandle isn't
stale anymore.  However nfs_refresh_inode doesn't use this information
to clear the NFS_INO_STALE flag.  Maybe it should.

In short, I really don't think that NFS_INO_STALE (or any other item
if information received from the server) should be considered to be
permanent and never rechecked.

NeilBrown


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

Re: Stale NFS handles on 2.4.2

[Trond Myklebust]

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

     > In short, I really don't think that NFS_INO_STALE (or any other
     > item if information received from the server) should be
     > considered to be permanent and never rechecked.

There are 2 problems of inode corruption if you allow inodes to die
and then reappear at will:

  1) is that several servers, including the userspace nfsd, have
     problems with filehandle reuse. You do not want to fall victim
     either to corruption either of the inode cache or (worse) the
     file itself.

     In the same vein, consider all these horror stories about people
     sharing CDROMs over NFS, mounting/umounting them at will...

  2) Even on servers that strictly respect the uniqueness of
     filehandles you can risk cache/file corruption due to inode
     aliasing when for instance you are using shared mmap between 2
     processes.

     For instance: under a lookup() operation, the client notices that
     the inode is stale, creates a new one (after unhashing the old
     one of course but otherwise not invalidating it).
     If the old inode is then magically declared to be OK, you
     suddenly have 2 inodes with 2 different caches that are
     supposed to represent the same file.

Of course, the second problem is not really relevant to the root
directory inode (which should never get aliased anyway). Perhaps the
correct thing to do would be to allow root inodes to clear the
NFS_INO_STALE flag? Something like the following...

Cheers,
   Trond

--- linux-2.4.2/fs/nfs/inode.c.orig	Wed Feb 14 01:14:28 2001
+++ linux-2.4.2/fs/nfs/inode.c	Thu Mar  1 02:08:59 2001
@@ -819,24 +819,22 @@
 int
 __nfs_revalidate_inode(struct nfs_server *server, struct inode *inode)
 {
-	int		 status = 0;
+	int		 status = -ESTALE;
 	struct nfs_fattr fattr;
 
 	dfprintk(PAGECACHE, "NFS: revalidating (%x/%Ld)\n",
 		inode->i_dev, (long long)NFS_FILEID(inode));
 
 	lock_kernel();
-	if (!inode || is_bad_inode(inode) || NFS_STALE(inode)) {
-		unlock_kernel();
-		return -ESTALE;
-	}
+	if (!inode || is_bad_inode(inode))
+ 		goto out_nowait;
+	if (NFS_STALE(inode) && inode != inode->i_sb->s_root->d_inode)
+ 		goto out_nowait;
 
 	while (NFS_REVALIDATING(inode)) {
 		status = nfs_wait_on_inode(inode, NFS_INO_REVALIDATING);
-		if (status < 0) {
-			unlock_kernel();
-			return status;
-		}
+		if (status < 0)
+			goto out_nowait;
 		if (time_before(jiffies,NFS_READTIME(inode)+NFS_ATTRTIMEO(inode))) {
 			status = NFS_STALE(inode) ? -ESTALE : 0;
 			goto out_nowait;
@@ -850,7 +848,8 @@
 			 inode->i_dev, (long long)NFS_FILEID(inode), status);
 		if (status == -ESTALE) {
 			NFS_FLAGS(inode) |= NFS_INO_STALE;
-			remove_inode_hash(inode);
+			if (inode != inode->i_sb->s_root->d_inode)
+				remove_inode_hash(inode);
 		}
 		goto out;
 	}
@@ -863,6 +862,8 @@
 	}
 	dfprintk(PAGECACHE, "NFS: (%x/%Ld) revalidation complete\n",
 		inode->i_dev, (long long)NFS_FILEID(inode));
+
+	NFS_FLAGS(inode) &= ~NFS_INO_STALE;
 out:
 	NFS_FLAGS(inode) &= ~NFS_INO_REVALIDATING;
 	wake_up(&inode->i_wait);

Re: Stale NFS handles on 2.4.2

[Trond Myklebust]

>>>>> " " == David Fries <dfries@umr.edu> writes:

     > If I didn't make it clear /home/david directory is the stale
     > NFS filehandle and server:/home is mounted on /home so it isn't
     > the root directory inode here that is having the problem.

Ah. Sorry... Neil's argumentation made me think it might be the root
inode that was stale. Indeed from the code that is currently a
pathology.

Hmm: it looks like the dentry revalidation code is in any case not
complete. Basically it doesn't check if the NFS_INO_STALE flag is set
when deciding whether or not a cached dentry is valid.

OK. We need the patch I sent last night plus a 1-liner in
nfs_inode_is_stale(). That should cover both pathologies. It'll
probably clean up the other cases in which people have been reporting
-ESTALE errors.

Cheers,
   Trond


--- linux-2.4.2/fs/nfs/inode.c.orig	Wed Feb 14 01:14:28 2001
+++ linux-2.4.2/fs/nfs/inode.c	Thu Mar  1 10:00:15 2001
@@ -632,7 +632,7 @@
 	if ((fattr->mode & S_IFMT) != (inode->i_mode & S_IFMT))
 		return 1;
 
-	if (is_bad_inode(inode))
+	if (is_bad_inode(inode) || NFS_STALE(inode))
 		return 1;
 
 	/* Has the filehandle changed? If so is the old one stale? */
@@ -819,24 +819,22 @@
 int
 __nfs_revalidate_inode(struct nfs_server *server, struct inode *inode)
 {
-	int		 status = 0;
+	int		 status = -ESTALE;
 	struct nfs_fattr fattr;
 
 	dfprintk(PAGECACHE, "NFS: revalidating (%x/%Ld)\n",
 		inode->i_dev, (long long)NFS_FILEID(inode));
 
 	lock_kernel();
-	if (!inode || is_bad_inode(inode) || NFS_STALE(inode)) {
-		unlock_kernel();
-		return -ESTALE;
-	}
+	if (!inode || is_bad_inode(inode))
+ 		goto out_nowait;
+	if (NFS_STALE(inode) && inode != inode->i_sb->s_root->d_inode)
+ 		goto out_nowait;
 
 	while (NFS_REVALIDATING(inode)) {
 		status = nfs_wait_on_inode(inode, NFS_INO_REVALIDATING);
-		if (status < 0) {
-			unlock_kernel();
-			return status;
-		}
+		if (status < 0)
+			goto out_nowait;
 		if (time_before(jiffies,NFS_READTIME(inode)+NFS_ATTRTIMEO(inode))) {
 			status = NFS_STALE(inode) ? -ESTALE : 0;
 			goto out_nowait;
@@ -850,7 +848,8 @@
 			 inode->i_dev, (long long)NFS_FILEID(inode), status);
 		if (status == -ESTALE) {
 			NFS_FLAGS(inode) |= NFS_INO_STALE;
-			remove_inode_hash(inode);
+			if (inode != inode->i_sb->s_root->d_inode)
+				remove_inode_hash(inode);
 		}
 		goto out;
 	}
@@ -863,6 +862,8 @@
 	}
 	dfprintk(PAGECACHE, "NFS: (%x/%Ld) revalidation complete\n",
 		inode->i_dev, (long long)NFS_FILEID(inode));
+
+	NFS_FLAGS(inode) &= ~NFS_INO_STALE;
 out:
 	NFS_FLAGS(inode) &= ~NFS_INO_REVALIDATING;
 	wake_up(&inode->i_wait);

Re: Stale NFS handles on 2.4.2^H^H^H^H^H2.2.19

[Trond Myklebust]

>>>>> " " == Patrick J LoPresti <patl@curl.com> writes:

     > Trond Myklebust <trond.myklebust@fys.uio.no> writes:
    >> OK. We need the patch I sent last night plus a 1-liner in
    >> nfs_inode_is_stale(). That should cover both pathologies. It'll
    >> probably clean up the other cases in which people have been
    >> reporting -ESTALE errors.

     > This would be great!

     > Any chance your patches will make it into 2.2.19?

They might if you can confirm that the latest 2.2.19-pre patch + the
appended fix the ESTALE problems.

(I hope there are no typos here. I'm preparing to fly over to the
Connectathon tonight, so I haven't had time to run a test, but the
conversion from 2.4.2 should be trivial...)

Cheers,
  Trond

diff -u --recursive --new-file linux-2.2.19-pre14/fs/nfs/inode.c linux-2.2.19-stale/fs/nfs/inode.c
--- linux-2.2.19-pre14/fs/nfs/inode.c	Thu Feb 22 20:47:54 2001
+++ linux-2.2.19-stale/fs/nfs/inode.c	Thu Mar  1 15:06:52 2001
@@ -689,7 +689,7 @@
 	if ((fattr->mode & S_IFMT) != (inode->i_mode & S_IFMT))
 		return 1;
 
-	if (is_bad_inode(inode))
+	if (is_bad_inode(inode) || NFS_STALE(inode))
 		return 1;
 
 	/* Has the filehandle changed? If so is the old one stale? */
@@ -871,7 +871,9 @@
 	dfprintk(PAGECACHE, "NFS: revalidating (%x/%Ld)\n",
 		inode->i_dev, (long long)NFS_FILEID(inode));
 
-	if (!inode || is_bad_inode(inode) || NFS_STALE(inode))
+	if (!inode || is_bad_inode(inode))
+		return -ESTALE;
+	if (NFS_STALE(inode) && inode != inode->i_sb->s_root->d_inode)
 		return -ESTALE;
 
 	while (NFS_REVALIDATING(inode)) {
@@ -889,7 +891,8 @@
 			 inode->i_dev, (long long)NFS_FILEID(inode), status);
 		if (status == -ESTALE) {
 			NFS_FLAGS(inode) |= NFS_INO_STALE;
-			remove_inode_hash(inode);
+			if (inode != inode->i_sb->s_root->d_inode)
+				remove_inode_hash(inode);
 		}
 		goto out;
 	}
@@ -903,6 +906,7 @@
 	dfprintk(PAGECACHE, "NFS: (%x/%Ld) revalidation complete\n",
 		 inode->i_dev, (long long)NFS_FILEID(inode));
 
+	NFS_FLAGS(inode) &= ~NFS_INO_STALE;
 out:
 	NFS_FLAGS(inode) &= ~NFS_INO_REVALIDATING;
 	wake_up(&inode->i_wait);

Re: Stale NFS handles on 2.4.2

[Trond Myklebust]

>>>>> " " == David Fries <dfries@umr.edu> writes:

     > I'ved tried `mount /home -o remount`, and reading lots of other
     > directories to flush out that entry if it was in cache without
     > any results.

     > I was hopping to avoid unmounting, as I would have to shut
     > about everything down to do that.

It looks as if you'll have to do that. 'mount -oremount' does not
really cause the root filehandle to get updated. The only thing it
does at the moment is allow you to change from a read-only to a
read-write filesystem.

What kind of filesystem is this BTW: is it an ext2 partition you are
exporting?

Cheers,
  Trond

Re: Stale NFS handles on 2.4.2

[Lennert Buytenhek]

On 25 Feb 2001, Trond Myklebust wrote:

>      > I was hopping to avoid unmounting, as I would have to shut
>      > about everything down to do that.
>
> It looks as if you'll have to do that. 'mount -oremount' does not
> really cause the root filehandle to get updated. The only thing it
> does at the moment is allow you to change from a read-only to a
> read-write filesystem.

A trick that works for me is mounting the NFS filesystem on another mount
point and unmounting it there. This usually makes the mount on the
original mount point magically work again.


cheers,
Lennert

Re: Stale NFS handles on 2.4.2

[David Fries]

On Mon, Feb 26, 2001 at 10:54:02AM +0100, Lennert Buytenhek wrote:
> A trick that works for me is mounting the NFS filesystem on another mount
> point and unmounting it there. This usually makes the mount on the
> original mount point magically work again.

Thinks, but I've tried it and it didn't work already.

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+