Messages in this thread | | | Date | Wed, 02 Sep 1998 18:10:41 +0100 | From | Richard Jones <> | Subject | Re: NFS: Hash collision with the root inode ??? |
| |
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
| |