From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 16:02:21 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 3EEB91065675; Sun, 6 Nov 2011 16:02:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B29E38FC13; Sun, 6 Nov 2011 16:02:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEmvtk6DaFvO/2dsb2JhbABChHqmIYFyAQEEASNWBRYYAgINGQJZBhOIAqJ7kHIEgTCGZYEWBIgLjBaSCg X-IronPort-AV: E=Sophos;i="4.69,464,1315195200"; d="scan'208";a="142856602" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Nov 2011 11:01:55 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C51BCB3F1E; Sun, 6 Nov 2011 11:01:55 -0500 (EST) Date: Sun, 6 Nov 2011 11:01:55 -0500 (EST) From: Rick Macklem To: Xin LI Message-ID: <858445532.1240736.1320595315792.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, Josh Paetzel , 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 16:02:21 -0000 Xin Li wrote: > Hi, Rick, >=20 > On Sat, Nov 5, 2011 at 6:18 PM, 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 > > =C2=A0non-volatile storage, the file modification will be lost. > > =C2=A0(When a server replies UNSTABLE to a write, the client holds > > =C2=A0 onto the data in its cache and does the write again if the > > =C2=A0 server crashes/reboots before the client does a Commit RPC > > =C2=A0 for the file. However, a reply of FILESYNC tells the client > > =C2=A0 it can forget about the write, because it is done.) > > - Because of the above, replying FILESYNC when the data is not > > =C2=A0yet committed to non-volatile (also referred to as stable) > > =C2=A0storage, this is a violation of RFC1813. > > > > I wouldn't want this to be the default, but am willing to > > patch head based on the "backwards compatibility" argument. > > My concern with these types of patches is that some people > > will enable them without realizing the risk of data loss > > that they introduce. > > > > So, how do others feel with respect to whether or not this > > patch should be committed to head? >=20 > I think the default of old NFS server was async=3D0? In general I'd > prefer seeing this as an option but disabled by default, so > administrators can override the option. Having async=3D1 by default > doesn't seem to be a good idea in my opinion. >=20 Yes, I agree. If I commit it, it will definitely not be enabled by default. The question I was asking was "Should it be committed at all?". > Another thought is the async flag should be a per-mountpoint flag > rather than a global flag, but that might be over-complicating things > so just my $0.02. >=20 Well, since it doesn't affect server file system behaviour and only the reply the NFS server sends to the client, I don't see it as a per-mountpoin= t flag on server file systems, but I'm really looking for what others think? > Cheers, > -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die