lkml.org 
[lkml]   [1998]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Strange problem with 2.0.34 NFS client and 2.1.125 (old user-space) NFS Server
Date
From
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/

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