Re: Strange problem with 2.0.34 NFS client and 2.1.125 (old user-space) NFS Server

Olaf Kirch (okir@monad.swb.de)
Fri, 30 Oct 1998 17:30:26 +0100

Jonas <linuxconf@qad-integral.de> wrote:
> There is one file, that on either directory read or stat(), turns the
> whole nfs tree in a single, normal file. The mount point turns out those
> normal, plain file. Sometimes I am able mv() the moint point, create a new
> one and remount. Sometimes the mv() hangs uninterruptable. I think this
> surely has something to do with the inode number. The file is physically
> on a different FS as the root inode that gets mounted.

Most likely, the problem is quite simple: unfsd, in order to export
an entire tree without caring for mount points, produces a 32 bit hash
from the file's real device/inode number and returns that as the file's
inode #. Now if you have a fairly big disk, you will inevitably end up
producing the same inode # for two different files/directories.

I have been trying to tackle the problem for a while now, but it is not
as easily solved as one might think. When unfsd was first designed,
nobody obivously imagined 9GB hard disks:-(

I've now come up with something that might solve your problem. Please
check out version 2.2beta38 from

ftp://linux.mathematik.tu-darmstadt.de/pub/linux/people/okir/dontuse,

and answer yes when the BUILD script asks you about the new inode
numbering scheme.

Olaf

-- 
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax


-
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/