From owner-freebsd-current@FreeBSD.ORG Sat Jun 29 09:13:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8F6AE5A4 for ; Sat, 29 Jun 2013 09:13:58 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by mx1.freebsd.org (Postfix) with ESMTP id 7942B1EBE for ; Sat, 29 Jun 2013 09:13:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,965,1363158000"; d="scan'208";a="30678739" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 29 Jun 2013 02:13:51 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.35]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Sat, 29 Jun 2013 02:13:50 -0700 From: "Eggert, Lars" To: Rick Macklem Subject: Re: NFSv4 console messages (locks lost etc.) Thread-Topic: NFSv4 console messages (locks lost etc.) Thread-Index: AQHOdAnBkCLwXfwr6ECtjlyrKEz+QJlMTaWAgACRjwA= Date: Sat, 29 Jun 2013 09:13:48 +0000 Message-ID: References: <604397759.54014.1372465971639.JavaMail.root@uoguelph.ca> In-Reply-To: <604397759.54014.1372465971639.JavaMail.root@uoguelph.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <6A6D8F498BD1FA4D87E22764F20C6367@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 09:13:58 -0000 Hi, I should have mentioned that the server is FreeBSD -STABLE running newnfs, = and the network isn't partitioned (because I access the box over SSH at the= same time I see these messages.) They only appear under heavy NFS load (portmaster build of math/R in this c= ase.) Lars On Jun 29, 2013, at 2:32, Rick Macklem wrote: > Lars Eggert wrote: >> Hi, >>=20 >> on a -CURRENT client, I get quite a number of console messages under >> heavy NFSv4 load, such as: >>=20 >> nfsv4 expired locks lost > Means the lease expired on the NFSv4 server somehow. Lease > expiry is "bad news" and there is no way to recover locks > lost because of it. >> nfscl: never fnd open > Usually, opens can be recovered after a lease expiry, but it > might be broken. Since lease expiry should never happen during > normal operation (see below), it doesn't get a lot of testing. >=20 >> nfscl: never fnd open >> nfscl: never fnd open >> nfsv4 expired locks lost >> nfscl: never fnd open >> nfscl: never fnd open >> nfsv4 expired locks lost >> nfsv4 expired locks lost >> nfsv4 expired locks lost >> nfsv4 expired locks lost >> nfsv4 expired locks lost >> nfscl: never fnd open >>=20 >> Can I ignore them? Can I turn them off? >>=20 > Well, these should never happen during normal, correct operation. The > "nfsv4 expired locks lost" implies lease expiry. This should only happen > when the client is network partitioned from the server for more than > a lease duration (chosen by the server, but typically about 1minute). > The client does a Renew Op every 1/2 lease durations to avoid this. Also, > any state related operation (open/lock/locku/close/etc) is supposed to > renew the lease implicitly. >=20 > If you are getting network partitions happening, then you really need > to fix the network. >=20 > If not, then if you watch network traffic with something like wireshark > and see Renew Ops happening at regular intervals, then I can only suggest > that the server is somehow broken for NFSv4. You should also look for > NFS4ERR_EXPIRED error replies to operations related to state (open/lock/l= ocku/close). > That is the server reply which indicates the lease expiry. If the server = is > never returning this, I have no idea how the client would generate the ab= ove > messages, but it does indicate a client NFSv4 bug if that is the case. >=20 > Switching all mounts to NFSv3 will get rid of the above, although it is > not exactly a fix;-) >=20 > rick >=20 >> Thanks, >> 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