From owner-cvs-src@FreeBSD.ORG Tue Apr 25 03:13:58 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 2146916A404 for ; Tue, 25 Apr 2006 03:13:58 +0000 (UTC) (envelope-from mohan_srinivasan@yahoo.com) Received: from web30813.mail.mud.yahoo.com (web30813.mail.mud.yahoo.com [68.142.201.139]) by mx1.FreeBSD.org (Postfix) with SMTP id D1DA143D49 for ; Tue, 25 Apr 2006 03:13:56 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: (qmail 3685 invoked by uid 60001); 25 Apr 2006 03:13:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NbrIhtssOs4KJNZinA90vKrf/3cwHu4uRWxbFZTC5Meo+JiCG/JtgvJ+8OSiCc9GUjD8MVznA4uymjc8oasN0R+pkf768X6w4WecAlXWse4ir29BofHS7bHQ/tRgIYcbCIYgiDR56g2G9MHMRlQUaL+XtV1SnEGpdz6C/NV+0+k= ; Message-ID: <20060425031356.3683.qmail@web30813.mail.mud.yahoo.com> Received: from [71.139.120.137] by web30813.mail.mud.yahoo.com via HTTP; Mon, 24 Apr 2006 20:13:56 PDT Date: Mon, 24 Apr 2006 20:13:56 -0700 (PDT) From: Mohan Srinivasan To: Sam Leffler , Kris Kennaway In-Reply-To: <444D7114.1020106@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 03:13:58 -0000 --- Sam Leffler wrote: > > > > 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? Most NFS server that I am aware of will scale the duplicate request cache based on the memory available (and we should probably do the same). It is very easy to overflow a 64 entry duplicate request cache though, and bumping it makes sense. So, this is not a bandaid. The real fix is to use NFS/TCP, although even there, the duplicate request cache cannot be completely eliminated, because a non-idempotent request can be re-transmitted after a connection teardown and re-establishment. mohan