Re: Re: Re: Re: Regression caused by commit 4bdc33ed("NFSDv4.2: Add NFS v4.2 support to the NFS server")

[Jongman Heo]

Hi,

>
>------- Original Message -------
>Sender : J. Bruce Fields<bfields@xxxxxxxxxxxx>
>Date : 2013-09-27 10:12 (GMT+09:00)
>Title : Re: Re: Re: Regression caused by commit 4bdc33ed ("NFSDv4.2: Add NFS v4.2 support to the NFS server")
>
>On Thu, Sep 26, 2013 at 11:57:57PM +0000, Jongman Heo wrote:
>> >------- Original Message -------
>> >Sender : J. Bruce Fields
>> >This is pretty weird--it's not at all obvious how that patch would
>> >affect this.
>> >
>> >You're absolutely positive that the *only* thing you're changing on the
>> >server between the "good" and "bad" cases is that one kernel patch?
>> >You're not changing anything in userspace?
>> >
>> 
>> Yes, pretty sure.
>> 
>> >What does "cat /proc/fs/nfsd/versions" report in the good and bad cases?
>> >
>> >(BTW, out of curiosity: what kind of client is this that only supports
>> >NFSv2 and NFSv3?  Even for an embedded system that's a bit surprising.)
>> >
>> >--b.
>> >
>> 
>> Here are /proc/fs/nfsd/versions information for good and bad cases ;
>> 
>> good (commit 4bdc33ed reverted)
>> 
>> # cat /proc/fs/nfsd/versions 
>> +2 +3 +4 +4.1
>> 
>> 
>> bad (current linus git)
>> 
>> # cat /proc/fs/nfsd/versions  
>> -2 +3 +4 +4.1 -4.2
>> 
>> 
>> I don't know why the commit 4bdc33ed makes this difference ( from +2 to -2 ).
>> 
>> My NFS server just uses Fedora 19 + latest kernel (which is not a rare setup...), 
>
>The thing is, nfs-utils *did* make exactly this change with commit
>6b4e4965a6b82e8d49cea1c0316b951ba4e9e83e "rpc.nfsd: No longer advertise
>NFS v2 support." in 1.2.9-rc4 which entered f19 recently.  And that
>kernel commit doesn't look related.  So I strongly suspect that you got
>the nfs-utils update (or rebooted after the update) at the same time as
>bisecting, and that confused the bisect results.
>

No, I haven't changed/upgraded nfs-utils package during git bisect.
And I can still reproduce the issue.

# rpm -qa|grep nfs-utils
nfs-utils-1.2.8-4.0.fc19.i686

# rpm -q --changelog nfs-utils|head -6
* Mon Aug 19 2013 Steve Dickson <steved@xxxxxxxxxx> 1.2.8-4.0
- Updated to latest upstream RC release: nfs-utils-1-2-9-rc4

* Tue Jul 23 2013 Steve Dickson <steved@xxxxxxxxxx> 1.2.8-3.0
- Updated to latest upstream RC release: nfs-utils-1-2-9-rc3

As you noticed, 1.2.9-rc4 is applied to Fedora 19's nfs-utils what I'm using...

With the nfs-utils, reverting the commit makes difference to me.


Another workaround from user-space (instead of revert) works for me.

Latest linus git gives following NFS version support (with my server's .config).

  # cat /proc/fs/nfsd/versions 
  -2 +3 +4 +4.1 -4.2

I've changed /etc/sysconfig/nfs file as following diff ;

@@ -10,7 +10,7 @@
 #LOCKD_UDPPORT=32769
 #
 # Optional arguments passed to rpc.nfsd. See rpc.nfsd(8)
-RPCNFSDARGS=""
+RPCNFSDARGS="-V 2"


Then. run nfs server again...

# systemctl restart nfs-server.service
# cat /proc/fs/nfsd/versions 
+2 +3 +4 +4.1 -4.2

Now NFS boot is working. 
Actually I'm OK with this, since NFS boot is just used for debugging purpose, not for production use, in my case.


FYI, in other Linux machine (Ubuntu 12.04), nfs-utils version is "1.2.5-3ubuntu3.1", and the kernel commit doesn't cause NFS v2 support issue.

# cat /proc/fs/nfsd/versions
+2 +3 +4 +4.1 -4.2

So, the change in nfs-utils 1.2.9-rc4 seems to be the root cause, but I don't know why the kernel commit revert resolves the issue.

>> so I think some people can verify if this version information change happens w/ and w/o the commit revert.
>> 
>> Don't know the detail of NFS protocol, but our NFS client seems not to try with v3 and v4 in case v2 fails...
>> Is this an unexpected (buggy) behavior of my old embedded box (NFS client of kernel 2.6.35), or expected one from the NFS protocol?
>
>Digging into a historical git repo just for fun.... It looks like NFSv3
>support was added in 2.3.99pre4-3, probably in 2000?  (The date on that
>commit is 2007, so obviously this repo I have is very confused.  Maybe I
>should go find if there's a better one someplace.)
>
>So anyway it's either configured out of the kernel or the mount
>commandline's asking for v2, or I don't know what....
>
>--b.
>

Thanks,
Jongman Heo.N‹§²æìr¸›yúèšØb²X¬¶ÇvØ^–)Þ{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü}©ž²ÆzÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ßf”ù^jÇy§m…á@A«a¶Úÿ0¶ìh®å’i