From owner-freebsd-stable@FreeBSD.ORG Thu Mar 4 23:31:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47698106566C; Thu, 4 Mar 2010 23:31:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id AFEAD8FC0A; Thu, 4 Mar 2010 23:31:00 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPzRj0uDaFvG/2dsb2JhbACbRXO3bYJegh4EgxeLIA X-IronPort-AV: E=Sophos;i="4.49,583,1262581200"; d="scan'208";a="67839054" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 04 Mar 2010 18:30:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id CBD9A350004; Thu, 4 Mar 2010 18:30:58 -0500 (EST) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBn9SSsV4-Dp; Thu, 4 Mar 2010 18:30:57 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 2CF7E210248; Thu, 4 Mar 2010 18:30:57 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o24NhAt07105; Thu, 4 Mar 2010 18:43:10 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 4 Mar 2010 18:43:10 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Daniel Braniss In-Reply-To: Message-ID: References: <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> <4B89943C.70704@digiware.nl> <20100227220310.GA65110@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org, freebsd-fs@freebsd.org, Willem Jan Withagen , =?utf-8?B?R2Vycml0IEvDvGhu?= , =?utf-8?B?RWlyaWsgw5h2ZXJieQ==?= , rwatson@freebsd.org, Jeremy Chadwick Subject: Re: mbuf leakage with nfs/udp (was mbuf leakage with nfs/zfs?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 23:31:01 -0000 On Thu, 4 Mar 2010, Daniel Braniss wrote: > > correct. The interesting side effect, is that I can't see any negative > issues when disabling the cash. If the client retries a non-idempotent RPC, the server will do it again, which can result in data corruption. This is likely to happen infrequently, but with potentially nasty results. (The paper that describes this was given at a late 1980s Usenix by Chet J. His name is in a comment somewhere, I think. I won't dare to try and spell it.:-) > seems ok, I have been running it now on a semi production server and > it's holding up quiet nicely, the cache seems not up to expectations: > > store-mg-03# nfsstat -se > Server Info: > Getattr Setattr Lookup Readlink Read Write Create Remove > 48176764 262687 12582599 19732 4225907 9186574 780793 818837 > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access > 7623 160 27753 59551 59552 118216 0 1992779 > Mknod Fsstat Fsinfo PathConf Commit LookupP SetClId SetClIdCf > 0 979005 19 0 1644267 0 0 0 > Open OpenAttr OpenDwnGr OpenCfrm DelePurge DeleRet GetFH Lock > 0 0 0 0 0 0 0 0 > LockT LockU Close Verify NVerify PutFH PutPubFH PutRootFH > 0 0 0 0 0 0 0 0 > Renew RestoreFH SaveFH Secinfo RelLckOwn V4Create > 0 0 0 0 0 0 > Server: > Retfailed Faults Clients > 0 0 0 > OpenOwner Opens LockOwner Locks Delegs > 0 0 0 0 0 > Server Cache Stats: > Inprog Idem Non-idem Misses CacheSize TCPPeak > 307 0 297 80943198 0 0 > If you are referring to the high miss rate, that is normal and to be expected. It's the 297 Non-idempotent hits that could have caused data corruption without the cache. When there is a hit, the RPC reply comes from the cache, so that the RPC isn't performed again on the server. (Some/many of these are not harmful. For example, a retried Remove simply fails with ENOENT, but others...) Glad to hear that the experimental server is working ok for you, rick