lkml.org 
[lkml]   [1998]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.1.103: knfsd dentry problem: x/y not found -- need full search
Austin Donnelly wrote:
> I've been running with knfsd as a module fine for a while now, first
> with 2.1.93, now with 2.1.103.
>
> I have a reproducible problem when untarring a file that's come in
> over an ssh link. The command in question looks like:
>
> myrddin$ ssh remote.machine "tar -cf - ." | tar -xvf -
>
> This command is run from ~/docs/ThesisProposal, (an empty directory), on
> myrddin, a 2.0.33 machine that has mounted my home directory from my
> machine valour via amd (Debian version upl102-22)
>
> The tar extract fails with ESTALE, but my machine's kernel nfsd
> complains:
>
> May 29 12:28:12 valour kernel: lookup_by_inode: docs/ThesisProposal inode mismatch??
> May 29 12:28:12 valour kernel: find_fh_dentry: 03:07, 129025/217178 not found -- need full search!
> May 29 12:28:12 valour kernel: find_fh_dentry: docs/ThesisProposal lookup mismatch!
> May 29 12:28:12 valour kernel: lookup_by_inode: found ThesisProposal
> May 29 12:28:12 valour kernel: lookup_by_inode: docs/ThesisProposal inode mismatch??
> May 29 12:28:12 valour kernel: find_fh_dentry: 03:07, 129025/217178 not found -- need full search!
>
> The inode number given for ~/docs is correct, but the one for
> ThesisProposal is off by one, ls -i shows it to be 217179. The
> ~/docs/ThesisProposal directory is empty.
>
> However, when I reboot to a 2.0.32 kernel, I find
> ~/docs/ThesisProposal (now inode 217178) contains just an empty
> directory, also called ThesisProposal (inode 217179).
>
> I can't reproduce this with:
>
> cat ../foo.tar | tar -xvf -
>
> It definately needs to be data from ssh, it seems.
>
> Has anyone seen similar behaviour? I don't have much time right now
> to look into it, but I might have more next week. Is Olav still
> maintaining the nfsd code?

Hi Austin,

I've done most of the recent work on knfsd, including the dentry
searching code that's complaining about not being able to find your
inodes. I haven't seen any other reports of this sort, and am not sure
what could be causing the problem.

It is possible that ssh is scrambling or encrypting the nfs filehandles?
The search code has to be able to get the right dentry and inode number
in order to find the files.

Regards,
Bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.043 / U:1.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site