NFSv4 console messages (locks lost etc.)
lars at netapp.com
Sat Jun 29 09:15:22 UTC 2013
Thanks Rick! I will check these Monday.
On Jun 29, 2013, at 2:45, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> Lars Eggert wrote:
>> On Jun 28, 2013, at 16:37, "Eggert, Lars" <lars at netapp.com> wrote:
>>> On Jun 28, 2013, at 16:14, "Eggert, Lars" <lars at netapp.com> wrote:
>>>> on a -CURRENT client, I get quite a number of console messages
>>>> under heavy NFSv4 load, such as:
>>>> 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).
>>> 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.
>> 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
> 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?
> 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.)
> 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?
> 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.
>> (I still get a bunch of "nfsv4 expired locks lost" messages, but no
>> freebsd-current at freebsd.org mailing list
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current