Thanks Rick! I will check these Monday. Lars On Jun 29, 2013, at 2:45, Rick Macklem <rmacklem_at_uoguelph.ca> wrote: > 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" >>Received on Sat Jun 29 2013 - 07:15:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC