Messages in this thread | | | Subject | 2.2.7 NFS v2 server "mutant" filehandles hurt on Solaris | From | Philippe Troin <> | Date | 05 May 1999 01:36:26 -0700 |
| |
I had quite a few troubles connecting Solaris NFS v2 clients on linux servers. Some typical behavior:
o Mounting goes fine for a while... o After some time, various clients get error in getpwd(). o If the mount point is not at the root of the exported fs, one can chdir() above the mount point but under the exported region. Eg: linux exports linux:/foo linux:/foo/bar is mounted on solaris:/mnt chdir(/mnt/junk) chdir(..) chdir(..) now you're in linux:/foo rather than being in solaris:/
o When this happens, the tcpdump shows that .. is looked up in the root of the exported filesystem (linux:/foo), and linux returns NFSERR_ACCESS (note that solaris returns NFSERR_NOENT).
o The trouble also happens when the linux server is rebooted.
My scenario to explain the problem is that solaris uses the root fh to remember when to switch back to the local fs. A linux client doesn't suffer from the problem because of the VFS . and .. magic (I think).
I came to the enclosed patch (not fully tested). It works by mapping the root of the exported directory to a special dentry (NFS_ROOTFH_MAGIC) when xdr'ing out the filehandles (and also while getting the root fh in nfsdcrl), and by remapping this special cookie back to the root dentry (as stored in the export entry) when validating the filehandle (I'm not sure that the export root dentry is reupdated when it changes in the export entry).
One remaining problem is that it won't work when mounting subdirectories within the mount point. I don't know how to handle this except by creating additional export entries for every requested mount point :-(
I can also think of other approaches: - marking all svc_fh that are requested by mountd with a don't prune from fhcache flag. (Problem: the dentry might vary accross reboots) - locking the dent in the dcache (suffers from the same problem, plus the dcache pruning might invalidate the dent).
I'm sure this patch is suboptimal. Anyone has a better idea ? However it seems to do the trick for mounting the exported directory.
NOTE: THIS IS NOT VERY WELL TESTED.
Phil.
[unhandled content-type:application/octet-stream]
| |