> My guess of what is happing here is that there the original
> dentry is flushed out of memory. Then when the file is next
> accessed the path has to be rebuilt. This generate all new
> dentries, so the search to find the export point fails.
>
> The solution might be:
>
> --- nfsfh.c.orig Sun Sep 12 23:15:35 1999
> +++ nfsfh.c Sun Sep 12 23:16:26 1999
> @@ -1124,7 +1124,7 @@
>
> do {
> tdentry = tdentry->d_parent;
> - if (exp->ex_dentry == tdentry)
> + if (exp->ex_dentry->d_inode->i_ino == tdentry->d_inode->i_ino)
> break;
> /* executable only by root and we can't be root */
> if (current->fsuid &&
>
>
> Or something a long those lines. (I am guessing.)
Well, we should probably also check the device... And a lot of code
checks also for the directory inode in case of a file (any clue why we
need to check dev/ino/dirino ? I thought that dev/ino ought to be
sufficient...)
Mmmh, I think there's something more subtle going on.
The problem lasts a few seconds where all fh lookups fail, and after
that everything is back to normal... If the original dentry were
flushed out, the problem would persist.
Plus, I think the export structure keeps the dentry locked.
But, I'm not a dcache guru anyways...
Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/