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>