Re: (was: nfs-utils-1.1.3 released)

[Chuck Lever <chuck.lever@oracle.com>]

On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
> Chuck Lever <chuck.lever@oracle.com> writes:
>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>> "J. Bruce Fields" <bfields@fieldses.org> writes:
>>>>
>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salaz=
ar
>>>>> wrote:
>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm havin=
g
>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>> tar ball is only available on SourceForge:
>>>>>>>
>>>>>>>   http://sourceforge.net/projects/nfs
>>>>>>> [...]
>>>>>>
>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>
>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>> mount
>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>> file
>>>>> access (which I'd expect to only involve the in-kernel client
>>>>> code) is
>>>>> failing.  Maybe there's some difference in the mount options?
>>>>> What does
>>>>> /proc/self/mounts say?  I assume these are all v2 or v3 mounts?
>>>>
>>>> I discovered today that I was no longer able to write to the v3
>>>> mount on
>>>> my 1.1.2 server.  I checked /proc/mounts and noticed sec=3Dnull on=
 =20
>>>> the
>>>> mount.  Either adding sec=3Dsys to the client's mount options or
>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>
>>> That would do it!
>>>
>>> So it sounds like there's a bug that causes mount.nfs to get the
>>> default
>>> mount options wrong?
>>
>> I'm not sure I'm following this.  I can't think of a user-space
>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>
>> Paul, which kernel are you running on your clients?
>
> Either 2.6.26 or 2.6.27-rc1+.  I'll double-check.

It would be interesting if you could try both.  I suspect 2.6.26 =20
doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount =20
parser that affect "sec=3D".

Also, enabling NFS mount debugging messages when performing the mount =20
that eventually doesn't work would be enlightening (for me).  Either:

   sudo sysctl -w sunrpc.nfs_debug=3D2048

or if you have the latest rpcdebug installed:

   sudo rpcdebug -m nfs -s mount

Then perform the mount.  Take a look in /var/log/messages for the =20
debugging messages.

And, please send the full command line of the failing mount request.

> Whichever one it was, the problem was present with 1.1.3 installed, =20
> and
> not present with 1.1.2 installed.

Gotcha.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com