Re: NFSv4 console messages (locks lost etc.)

Lars Eggert wrote:
> Hi,
> 
> 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
> crossed.
> 
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.

rick

> (I still get a bunch of "nfsv4 expired locks lost" messages, but no
> hangs.)
> 
> Lars
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"
>