From owner-freebsd-net@FreeBSD.ORG Thu Apr 7 20:10:01 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD50416A4CE for ; Thu, 7 Apr 2005 20:10:01 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8D2043D1D for ; Thu, 7 Apr 2005 20:10:01 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) id j37KA1Cj017953; Thu, 7 Apr 2005 13:10:01 -0700 (PDT) Received: from [10.1.1.245] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)j37K9xKq023093; Thu, 7 Apr 2005 13:10:00 -0700 (PDT) In-Reply-To: <42558F33.5090109@nersc.gov> References: <42558F33.5090109@nersc.gov> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Thu, 7 Apr 2005 16:09:58 -0400 To: dart@nersc.gov X-Mailer: Apple Mail (2.619.2) cc: freebsd-net@freebsd.org Subject: Re: Disable NFS client cache (or other traffic reduction methods) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2005 20:10:02 -0000 On Apr 7, 2005, at 3:51 PM, Eli Dart wrote: > Looking at the packet contents, it appears to be fetching back the > last few blocks of the log file. > > My guess is that this is the client keeping its NFS cache fresh. > The client is never, ever, ever going to read that file (or any file > on that filesystem) other than the bare minimum required to open it > for writing and rotate the log files. > > Is there a way to disable client-side caching? I've looked, and > can't seem to find one. Or, do I have this wrong and there is > something else that is causing this? Take a look through "man mount_nfs" for: -a Set the read-ahead count to the specified value. This may be in the range of 0 - 4, and determines how many blocks will be read ahead when a large file is being read sequentially. Trying a value greater than 1 for this is suggested for mounts with a large bandwidth * delay product. ...and the -o ac*** options. Although you may be right-- I was a bit surprised not to see a "-o noac", myself. Solaris has one: noac Suppress data and attribute caching. :-) -- -Chuck