From owner-cvs-src@FreeBSD.ORG Tue Apr 25 00:45:11 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E07E116A402; Tue, 25 Apr 2006 00:45:10 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48C5743D49; Tue, 25 Apr 2006 00:45:10 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k3P0j8mP020735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2006 17:45:09 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <444D7114.1020106@errno.com> Date: Mon, 24 Apr 2006 17:45:08 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5 (X11/20060210) MIME-Version: 1.0 To: Kris Kennaway References: <200604250021.k3P0LvUZ033748@repoman.freebsd.org> <444D6D54.1000007@errno.com> <20060425003615.GA21881@xor.obsecurity.org> In-Reply-To: <20060425003615.GA21881@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Mohan Srinivasan Subject: Re: cvs commit: src/sys/nfsserver nfsrvcache.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 00:45:11 -0000 Kris Kennaway wrote: > On Mon, Apr 24, 2006 at 05:29:08PM -0700, Sam Leffler wrote: >> Mohan Srinivasan wrote: >>> mohans 2006-04-25 00:21:57 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/nfsserver nfsrvcache.h >>> Log: >>> Bump up the NFS server dupreq cache limit to 2K (from 64). With a small >>> duplicate request cache, under heavy load a lot of non-idempotent >>> requests >>> were getting served again, resulting in errors. >> How does increasing the cache size fix this problem? > > Fundamentally it doesn't, this change just pushes it out of the regime > where it's trivial to overflow. Why is it hard to do a real fix? Or is this a temporary bandaid? Sam