NFS Server ...

[ogenos]

Dear Forumists,

I have had a nagging problem with a cross-compiler linux/solaris since kernel 3.4.34. To describe the situation: The linux side exposes a user directory through the NFS server and the SunOS side shares this directory as a client. The NFS version used is 3. The cross-compiler compiles files in this directory using the "linux" CPU and then compiles some more files in the same directory using the "solaris" CPU. Everything was running great up to kernel 3.4.34. With newer kernel versions the compiler on the solaris side couldn't find the Makefile, and when I forced a "-f ./Makefile" on it, couldn't find the rules within the Makefile. Now all scripts are written from GE engineers, and tested over and over, nevertheless I thought that with all this wealth of progress in shells and computation platforms somehow the coherency of the cross-compiler scripts was lost.

A day or two ago I came across this post (http://permalink.gmane.org/gmane.linux.nfs/60163) and I understood almost nothing of it but for the fact that the new 64BIT kernel cookies make files in a directory on a SunOS computer not list properly if this directory is NFS mounted from some other linux computer.

Anyway, to test this "hypothesis", I edited the /usr/src/linux-3.12.20-gentoo/fs/nfsd/vfs.c, modified the line 2099 which belongs to the nfsd_readdir() from if (rqstp->rq_vers > 2) to if (rqstp->rq_vers > 3) and recompiled the kernel. I had ZERO expectations when I tested the cross-compiler with the freshly installed kernel. I was astonished when it ran to completion without a problem. Note that kernel 3.4.34 doesn't present this problem with the 64BIT cookies.

This points to a problem with newer NFSs...

My setup:
linux: Linux **** 3.12.20-gentoo i686 Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz GenuineIntel GNU/Linux
solaris: SunOS **** 5.10 Generic_137137-09 sun4u sparc SUNW,Sun-Blade-1500

[Hu]

You did not ask a direct question, so I must ask what you want us to do about it. You seem to have found a workaround. Are you asking that the workaround be made a standard feature in the Linux nfsd? Are you hoping we can help you get your SunOS clients patched to work correctly when 64-bit cookies are enabled, as Linux clients already work correctly?

[ogenos]

Hello Hu,

I don't think the above is a workaround, it simply shows that there is an inconsistency problem with NFS. The SunOS 5.10 and its NFS v.3 client connects very well with kernel 3.4.34, NFS v.3 server and its 64-bit cookies. The problem surfaced with newer kernels, and is related to 64-bit cookies(?!). Why do you think its a SunOS problem? I, of course, don't want to tinker with the kernel and hope new kernels to still work with relatively old devices. I don't even know why there must be problems if NFS v.4 is used instead of v.3 when sharing with SunOS.

[Hu]

This is the first I have seen of Linux 64-bit NFS cookies causing problems. I assume that if the problem were with the Linux NFS server, that there would be other devices reporting problems and that the change would have been reverted in short order. Therefore, either Linux is out of specification to do this and most devices handle it anyway or Linux is within specification to do this and SunOS is out of specification for failing.

I have seen NFS-related commits to the upstream kernel from contributors employed by companies that sell Linux-based NFS appliances, such as Network Appliance and EMC. I assume that such people are competent at their job and reasonably familiar with the NFS specifications, since their devices must interoperate with any NFS clients that their customers purchase. Therefore, I assume that such people would not knowingly violate the specification in a way that breaks clients this badly.