I noticed the same problem at my site. fsid's in readdirplus on the Tru64 server not being the same as other NFS procedures returned by the Tru64 NFS server. I was able to see this in my network trace. And disabling READDIRPLUS allowed everything to work again.

This "32bitclients" NFS export option, you sure this is a Tru64 NFS server feature?

I added this option to my NFS export on the Tru64 NFS server, but still have the same problem. I assume Tru64 is ignoring this NFS export option?
I have seen this NFS export option on SGI and OSX servers. If Tru64 supports 32bitclients, it is not documented that I could find.

-Dan

Trond Myklebust wrote:

On Mon, 2007-03-05 at 15:35 -0500, Steve Dickson wrote:

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:


Sorry, but I really do not like the idea of fixing server bugs in the
Linux client, and particularly not in generic code like this.

As far as I understood, this was a direct consequence of using the
32bitclients export option to work around the old issues with 64-bit
cookies on readdir. Is there really a need for this option now that
we've ensured that readdir cookies are no longer exported to userland?

Cheers
  Trond

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs