From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 15:34:10 2011 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 4883C1065670; Sun, 6 Nov 2011 15:34:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id CA72B8FC1D; Sun, 6 Nov 2011 15:34:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAIiotk6DaFvO/2dsb2JhbABChHqmIYFyAQEFI1YbGAICDRkCWQYTqweQeIEwhmWBFgSIC4wWkgo X-IronPort-AV: E=Sophos;i="4.69,464,1315195200"; d="scan'208";a="144386883" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 06 Nov 2011 10:34:08 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E5928B3F07; Sun, 6 Nov 2011 10:34:08 -0500 (EST) Date: Sun, 6 Nov 2011 10:34:08 -0500 (EST) From: Rick Macklem To: Ronald Klop Message-ID: <1391798614.1239830.1320593648931.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Josh Paetzel , freebsd-fs@freebsd.org, zkirsch@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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: Sun, 06 Nov 2011 15:34:10 -0000 Ronald Klop wrote: > On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem > > wrote: > > > Hi, > > > > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > > for the new NFS server. > > > > I don't think I had spotted this before, but when I looked I > > saw that, when vfs.nfsrv.async is set non-zero in the old server, > > it returns FILESYNC (which means the write has been committed to > > non-volatile storage) even when it hasn't actually done that. > > > > This can improve performance, but has some negative implications: > > - If the server crashes before the write is committed to > > non-volatile storage, the file modification will be lost. > > (When a server replies UNSTABLE to a write, the client holds > > onto the data in its cache and does the write again if the > > server crashes/reboots before the client does a Commit RPC > > for the file. However, a reply of FILESYNC tells the client > > it can forget about the write, because it is done.) > > - Because of the above, replying FILESYNC when the data is not > > yet committed to non-volatile (also referred to as stable) > > storage, this is a violation of RFC1813. > > Just out of curiosity. Why would lying about FILESYNC improve > performance > over UNSTABLE? The server does the same work. Only the client holds > data > longer in memory. I only see impact if the client has just a little > bit of > memory. > > Ronald. Well, I'm not sure I have an answer. Josh noted that it makes a big difference for them. Maybe he can elaborate? One additional effect is that the client in head must do a synchronous write (with FILESYNC and waiting for the RPC reply) before it can modify a non-continuous region of the same buffer with respect to the old dirty byte region. (This happens frequently during builds, done mostly by the loader, I think?) If the server replies FILESYNC, then the old dirty byte region is done (ie. no longer a dirty byte region) so the client doesn't have to do the synchronous write described above. I hope that the experimental patch I made available a few days ago, along with work jhb@ is doing will eventually fix this for the FreeBSD client, but it won't be in head anytime soon (and who knows what other clients do?). rick