Messages in this thread | | | Subject | Re: Strange problem with 2.0.34 NFS client and 2.1.125 (old user-space) NFS Server | Date | Fri, 30 Oct 1998 17:30:26 +0100 | From | Olaf Kirch <> |
| |
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/
| |