Re: NFS: Hash collision with the root inode ???

Richard Jones (rjones@orchestream.com)
Wed, 02 Sep 1998 18:10:41 +0100

Bill Hawes wrote:
>
> Matthias Urlichs wrote:
> > I have a VERY strange NFS error here.
> >
> > Whenever I lstat() a certain file across NFS, the call succeeds, but all
> > accesses afterwards return EIO. The kernel logs:
> It's certainly possible (though unlikely) to get a inode hash collision
> with the unfsd server. To check this out, you could look up the inode
> number of the file in question on its native filesystem, and then run
> that through the unfsd hash algorithm. If it matches the inode number
> reported in the kernel messages, that would confirm your conjecture.
>
> If this is what's happening, there are some ways unfsd could be modified
> to avoid the problem.

That's interesting. I wonder if this is in some way related
to the strange behaviour we see with Sun clients. Occasionally
object files (*.o, and only *.o files produced by Sun's assembler)
become mangled so that any access to the file by name
produces:

file.o: Is a directory

Removing, touching, etc. makes no difference. You have to
remount the filesystem to make it work again. Looking at
tcpdump shows that it's unfsd's fault: in response to a
stat on the file, it really does return mode = 04xxxx (ie.
S_IFDIR + whatever).

Rich.

-- 
Richard Jones rjones@orchestream.com Tel: +44 171 598 7557 Fax: 460 4461
Orchestream Ltd.  125 Old Brompton Rd. London SW7 3RP PGP: www.four11.com
"boredom ... one of the most overrated emotions ... the sky is made
of bubbles ..."   Original message content Copyright © 1998


-
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.altern.org/andrebalsa/doc/lkml-faq.html