From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 03:03:48 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 0EFE2106566C for ; Sun, 6 Nov 2011 03:03:48 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7F48FC17 for ; Sun, 6 Nov 2011 03:03:47 +0000 (UTC) Received: by qyk9 with SMTP id 9so3299668qyk.13 for ; Sat, 05 Nov 2011 20:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=elJ/UP0pleKJ6RiTnkvB8uKyqxCBciQAS2y6FVptKYc=; b=b9fVOfSHxcLCG25h5215Xrh55NuyHJc7gMlFHKxxauY3appl+M9w4XmhplVD0fYy4O dxmx/VbEkzPFczEFpmTWJTyE6dnjk47YheKZbKTIVaGlK3LtDyV9R8x3MN9uQxS4wyZJ jptHmC9rkmlBU/nUmHwJtXxthd1cgBObLJRU0= MIME-Version: 1.0 Received: by 10.229.61.96 with SMTP id s32mr834216qch.46.1320548625193; Sat, 05 Nov 2011 20:03:45 -0700 (PDT) Received: by 10.229.1.233 with HTTP; Sat, 5 Nov 2011 20:03:44 -0700 (PDT) In-Reply-To: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> References: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 5 Nov 2011 20:03:44 -0700 Message-ID: From: Xin LI To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 03:03:48 -0000 Hi, Rick, 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? 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. 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. Cheers, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die