NFSv3 pathname problems in 2.4 kernels

NFSv3 pathname problems in 2.4 kernels

[Gordon Lack]

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

Re: NFSv3 pathname problems in 2.4 kernels

[Neil Brown]

On Sunday July 22, gmlack@freenet.co.uk wrote:
>    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). 

This shouldn't be a problem for Solaris 2.6, but definately is for
Irix.

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

Yes.  It has been reported on the nfs@lists.sourceforge.net list
several times.

> 
> b) if so, do they have a solution?

1/ Don't use irix.
2/ Don't use NFSv3
3/ Get a patch from Irix... I believe an upcoming release of Irix
fixed the problem, but I don't recall the details.

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

Look in fs/nfsd/nfsfh.c, in fh_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.

As far as making Linux "optimally compatible", I tend to agree.
There are hacks in place for Solaris7 which confuses itself with
exclusive creates, and for Tru64 which doesn't include UID information
in locking requests.
However in this case it is a clear and blatant bug in Irix client
code, not a subtly different interpretation or anything forgivable.

It might make sense to have a "broken_client" export option which 
always uses long filehandles...

> 
>    Hoping someone can help...

"Best" option is to complain to SGI and get a patch.

NeilBrown

Re: NFSv3 pathname problems in 2.4 kernels

[Gordon Lack]

Neil Brown wrote:
> 
> 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).

> > b) if so, do they have a solution?
> 
> 1/ Don't use irix.

   Not an option!

> 2/ Don't use NFSv3

   Not an option - some of the files are multi-GB ones.

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

> Look in fs/nfsd/nfsfh.c, in fh_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....

> "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...

Re: NFSv3 pathname problems in 2.4 kernels

[Neil Brown]

On Monday July 23, gmlack@freenet.co.uk wrote:
> Neil Brown wrote:
> > 
> > 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).

Odd indeed.  I use 2.6 systems and they seem fine.  I have only had
the problem when using an old version of mountd.  What verion of
nfs-utils are you using?

> > Look in fs/nfsd/nfsfh.c, in fh_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....

It should work for xfs, and infact everything but reiserfs as it is
the only filesys that currently sets dentry_to_fh.
However a better, more general solution would be to add a line:

 if (fhp->fh_handle.fh_size < NFS_FHSIZE)
     fhp->fh_handle.fh_size = NFS_FHSIZE;

just before the "return 0" in fh_update, and

 if (inode && fhp->fh_handle.fh_size < NFS_FHSIZE)
     fhp->fh_handle.fh_size = NFS_FHSIZE;

before the "return 0" in fh_compose.

NeilBrown