NFSv3 pathname problems in 2.4 kernels
I am seeing a problem at the client side when trying to obtain pathnames of NFS-mounted entries. This occurs when the NFS servers involved are Linux2.4 kernels and the clients are SGI Irix 6.5 or Solaris 2.6 (Linux 2.4 clients are Ok - 2.2 ones won't be using NFSv3).
As an example of what happens.
o The server side has a pathname of /raid/sources/prog1 - a directory.
o /raid is exported
o The client NFS mounts /raid/sources as /projects/sources
o I cd to /projects/sources/prog1 and type /bin/pwd
I expect to get /projects/sources/prog1 as the result, but I actually get /sources/prog1.
Similar mounts from Linux2.2. systems (presumably running NFSv2) produce the expected (correct) result.
I've snoop'ed the network traffic and one thing I can see is that the filehandle used in the NFSv3 mount is reported as being a different length (shorter) than those for v2.
So,
a) has anyone else encountered these problems?
b) if so, do they have a solution?
c) how is the filehandle calculated in the 2.4 kernel for NFSv3? Which routine is it in? Perhaps I could try (optionally) forcing it to be the same length as a v2 filehandle to see whether that fixes things. (I'd rather that the 2.4 kernel were optimally compatible rather than paranoically correct.
Hoping someone can help...
Quoted 3 lines · Neil Brown
This shouldn't be a problem for Solaris 2.6, but definately is for Irix.
Well, there are many 2.6 systems and they all fail in the same aay
as Irix. So does Solaris 2.7. (2.8 seems to be Ok).
Quoted 3 lines
Quoted 1 line
b) if so, do they have a solution?
1/ Don't use irix.
Not an option!
Quoted 1 line
2/ Don't use NFSv3
Not an option - some of the files are multi-GB ones.
Quoted 2 lines
3/ Get a patch from Irix... I believe an upcoming release of Irix fixed the problem, but I don't recall the details.
Fixed in 6.5.13 (I believe) but that requires fixing it in *many* clients, and doesn't help the
Solaris2.6/2.7 systems.
Quoted 8 lines
Look in
fs/nfsd/nfsfh.c, infh_compose.
If you change:if (ref_fh && ref_fh->fh_handle.fh_version == 0xca && parent->d_inode->i_sb->s_op->dentry_to_fh == NULL) { to if (parent->d_inode->i_sb->s_op->dentry_to_fh == NULL) {you will probably get what you want, for ext2 at least.
Thanks, but this is for xfs (I didn't fancy fsck'ing a 470GB file
system!). I suppose it's suck it and see....
Quoted 1 line
"Best" option is to complain to SGI and get a patch.
Not necessarily. That is certainly a long(ish)-term path, but there
are *far* more clients than servers, so a server-side fix, even if just a temporary fudge, is must better in practical terms. Change Control procedures for systems is more accurately described as Change Prevention!
Many thanks...