From owner-freebsd-fs@FreeBSD.ORG Fri Feb 6 16:55:43 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BFA21065672 for ; Fri, 6 Feb 2009 16:55:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from aeryn.cs.uoguelph.ca (aeryn.cs.uoguelph.ca [131.104.20.160]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4D98FC0A for ; Fri, 6 Feb 2009 16:55:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by aeryn.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n16GYS5n022004; Fri, 6 Feb 2009 11:34:29 -0500 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n16GcFf08129; Fri, 6 Feb 2009 11:38:15 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 6 Feb 2009 11:38:14 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Joe7 In-Reply-To: <20090205212511.jrmipmazeo4o0c8w@www.site.hu> Message-ID: References: <20090205212511.jrmipmazeo4o0c8w@www.site.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.20.161 Cc: freebsd-fs@freebsd.org Subject: Re: nfs delay causing broken files X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:55:44 -0000 On Thu, 5 Feb 2009, Joe7 wrote: > > Hi there, > > I'd like to know how to tune NFS (or related kernel) settings so the NFS > client writes would have NO delay? > I'm getting application level errors as NFS client writes data, then > application would read the data from NFS master just 1 second later and it's > not there yet, so outdated data is read. > You will have to enable synchronous writing (which will be a big performance hit, but...): - either mount with the "sync" option OR - have the apps open the files with O_SYNC (or O_FSYNC) If the recent writes need to be visible on other clients (and not just the NFS server), you will also have to bypass the client side caching for readers. This can be done by setting nfs_directio_enable to non-zero using sysctl and opening the files with O_DIRECT. (I think setting acregmax=0 as a mount option should achieve the same result, if you can't add O_DIRECT to the apps.) Again, a big performance hit, but... As an historical aside, way back when (before NFSv3) I concocked something callled not quite nfs, which included a cache coherency protocol, but it didn't catch on. Cache coherency seems to have never been a priority for the NFS crowd. Even in NFSv4, there isn't a cache coherency protocol, nor any interest in adding one. (In fairness, coherency between multiple clients can be achieved in NFSv4 for data by the clients putting byte range locks on all the byte ranges.) rick