Over the last new months, I've been getting beaten up
about the fact the Fedora Core clients (FC5 and FC6)
no loner works with Tru64 server. The problem is
accessing mounted directories would fail with -ENOTDIR.
Similar to:

# ls /mnt/alpha/doc
/bin/ls: cannot open directory /mnt/alpha/doc: Not a directory

After months of floundering around looking at ethereal
traces and such, I actually was able to trace down a
Tru64 server to test against (thanks you very much HP!).

Low and behold... it turns not to be a Linux client
bug at all... but only Linux clients failed because
they seem to actually care what fsids are being returned.

The problem is this: Tru64 server exporting Advfs fileystems
return sign extend fsids in most but not all NFS procedures.

Meaning most fattrs returned by the server have a fsid of:
     fsid: 0xffffffff8419f8d5

but in some procs (like READDIRPLUS) the fsid is
     fsid: 0x000000008419f8d5

Which is _clearly_ wrong and does not happen with UFS
exports on the same server.

So its my contention that Tru64 has been broken forever
since only Linux clients fail, which started due to the
following patch that went into 2.6.12:

commit 55a975937d40cac582e981ddc8ed783b3dcc043c
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Fri Jun 9 09:34:19 2006 -0400

   NFS: Ensure the client submounts, when it crosses a server mountpoint.

In this patch, fsids are compared to the first fsid that was received
during the mount ala:

@ -877,6 +883,11 @@ nfs_fhget(struct super_block *sb, struct nfs_fh *fh, 
struct
     if (nfs_server_capable(inode, NFS_CAP_READDIRPLUS)
         && fattr->size <= NFS_LIMIT_READDIRPLUS)
            set_bit(NFS_INO_ADVISE_RDPLUS, &NFS_FLAGS(inode)
+          /* Deal with crossing mountpoints */
+          if (!nfs_fsid_equal(&NFS_SB(sb)->fsid, &fattr->fsid)) {
+               inode->i_op = &nfs_mountpoint_inode_operations;
+               inode->i_fop = NULL;
+          }
(Although its a bit different in today kernel) setting i_op to
nfs_mountpoint_inode_operations causes lookups to fail with
ENOTDIR in __link_path_walk() due the following check:

     if (lookup_flags & LOOKUP_DIRECTORY) {
         err = -ENOTDIR;
         if (!inode->i_op || !inode->i_op->lookup)
             break;
     }
since i_op->lookup == NULL in the nfs_mountpoint_inode_operations
structure.

Now it must be the case that only Linux clients do this type of cross
mount checking since it appears other clients don't seem to
fail in a similar fashion (at least I have not heard of any).

So the question is what to do....

Now it's a well know fact that Tru64 is on its death bed which means
its in maintenance mode and the chances of it getting fixed are slim
to none... And one could argue, that since Linux clients once did
at one time worked with Tru64 servers and only the Linux client have
changed, the Linux client should make some effort to once again
interoperable with these types servers.  I personally don't agree with
this, one should never fix client for a broken server.... but... in my
world these type of problems are called regressions... So,
unfortunately, I need to do anything and everything (with reason) to
fix these types of problems...

So with that said... attached is that patch that does indeed
fix this problem. As the comments states, the received fsid
is signed extend and then is rechecked after the first
comparison fails.


I hopeful this will be accept...

steved.