Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Jun 2013 09:15:18 +0000
From:      "Eggert, Lars" <lars@netapp.com>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: NFSv4 console messages (locks lost etc.)
Message-ID:  <02A7574B-7425-47D5-A887-FC07C011E02E@netapp.com>
In-Reply-To: <301292118.57276.1372466730396.JavaMail.root@uoguelph.ca>
References:  <301292118.57276.1372466730396.JavaMail.root@uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Rick! I will check these Monday.

Lars

On Jun 29, 2013, at 2:45, Rick Macklem <rmacklem@uoguelph.ca> wrote:

> Lars Eggert wrote:
>> Hi,
>>=20
>> On Jun 28, 2013, at 16:37, "Eggert, Lars" <lars@netapp.com> wrote:
>>> On Jun 28, 2013, at 16:14, "Eggert, Lars" <lars@netapp.com> wrote:
>>>> on a -CURRENT client, I get quite a number of console messages
>>>> under heavy NFSv4 load, such as:
>>>>=20
>>>> nfsv4 expired locks lost
>>>> nfscl: never fnd open
> The "never fnd open" message is generated by the NFSv4 client when
> a close can't find an extant open to close. I suspect the "open" was
> not recovered after lease expiry. Since Close Ops only matter to the
> NFSv4 server, this doesn't imply a problem unless the NFSv4 server
> thinks the client still has an Open (which would not be the case after
> an NFSv4 server expires a lease, since it assumes all state such as opens
> are lost when a lease is expired).
>=20
>>>=20
>>> actually, not sure if the "nfscl" message is from an NFSv4 mount
>>> point or not, because the box mounts root via BOOTP, so with NFSv3
>>> (or v2?) and some other mounts with NFSv4.
>>=20
>> and another data point: the "nfscl" messages seem to disappear when I
>> remove the BOOTP_NFSV3 flag from the kernel. The client hangs that
>> made me dig into these messages seem to also disappear, fingers
>> crossed.
>>=20
> Hmm, weird, since NFSv3 should never generate these messages. I think
> that a root fs is remounted using the "/" entry in the /etc/fstab in the
> NFS mounted root fs. Did this entry specify "nfsv4" by any chance?
>=20
> Btw, a NFSv4 mounted root fs will not work correctly, because the client
> name is generated from the host uuid, which isn't set when the root fs
> is mounted. I'm not sure what the client would use as its client name,
> but this will definitely break things badly if multiple clients use the
> same name. (And this might explain the lease expiry problem.)
>=20
> If the root fs is mounted NFSv3 (or NFSv2) it shouldn't generate the
> messages or have any effect on the NFSv4 client, so I have no idea
> why removing BOOTP_NFSV3 would have any effect on this?
>=20
> Oh, and if you are using a pretty up to date system, you can "nfsstat -m"
> to find out what mount options are actually in use. If "nfsv4" is listed
> for your root fs, that is a serious problem that you need to fix.
>=20
> rick
>=20
>> (I still get a bunch of "nfsv4 expired locks lost" messages, but no
>> hangs.)
>>=20
>> Lars
>> _______________________________________________
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscribe@freebsd.org"
>>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02A7574B-7425-47D5-A887-FC07C011E02E>