Re: Stale NFS handles on 2.4.2^H^H^H^H^H2.2.19
> " " == Patrick J LoPresti <[EMAIL PROTECTED]> writes:
> Trond Myklebust <[EMAIL PROTECTED]> 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(>i_wait);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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(>i_wait);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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^H^H^H^H^H2.2.19
" " == Patrick J LoPresti [EMAIL PROTECTED] writes:
Trond Myklebust [EMAIL PROTECTED] 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);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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
> " " == Neil Brown <[EMAIL PROTECTED]> 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(>i_wait);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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
On February 28, [EMAIL PROTECTED] wrote: > > " " == Neil Brown <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
> " " == Neil Brown <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
" " == Neil Brown [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On February 28, [EMAIL PROTECTED] wrote: " " == Neil Brown [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
" " == Neil Brown [EMAIL PROTECTED] 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);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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
On Sunday February 25, [EMAIL PROTECTED] wrote: > On Sun, Feb 25, 2001 at 08:25:10PM +1100, Neil Brown wrote: > > On Saturday February 24, [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Sunday February 25, [EMAIL PROTECTED] wrote: On Sun, Feb 25, 2001 at 08:25:10PM +1100, Neil Brown wrote: On Saturday February 24, [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Sun, Feb 25, 2001 at 08:25:10PM +1100, Neil Brown wrote: > On Saturday February 24, [EMAIL PROTECTED] 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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Saturday February 24, [EMAIL PROTECTED] 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| > | [EMAIL PROTECTED] | > +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Saturday February 24, [EMAIL PROTECTED] 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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Sun, Feb 25, 2001 at 08:25:10PM +1100, Neil Brown wrote: On Saturday February 24, [EMAIL PROTECTED] 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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Sun, Feb 25, 2001 at 04:43:46PM +1100, Neil Brown wrote: > On Saturday February 24, [EMAIL PROTECTED] 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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Saturday February 24, [EMAIL PROTECTED] 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| > | [EMAIL PROTECTED] | > +-+ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Saturday February 24, [EMAIL PROTECTED] 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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
On Sun, Feb 25, 2001 at 04:43:46PM +1100, Neil Brown wrote: On Saturday February 24, [EMAIL PROTECTED] 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| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
