From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 23:58:15 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 7932A106566B for ; Wed, 27 Apr 2011 23:58:15 +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 354418FC17 for ; Wed, 27 Apr 2011 23:58:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAICsuE2DaFvO/2dsb2JhbACEU6IjiHCqSZEhgSmDUH0EjlGOSA X-IronPort-AV: E=Sophos;i="4.64,277,1301889600"; d="scan'208";a="119722246" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 27 Apr 2011 19:58:14 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 93632B3F33; Wed, 27 Apr 2011 19:58:14 -0400 (EDT) Date: Wed, 27 Apr 2011 19:58:14 -0400 (EDT) From: Rick Macklem To: Chris Forgeron Message-ID: <640208384.682241.1303948694525.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.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: make the experimental NFS subsystem the default one 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: Wed, 27 Apr 2011 23:58:15 -0000 > Yes, as I noted in my message, you can't enable async client side - > It's inside of ESX, and you don't have an option to modify. > > And yes, it would also mean that you could really screw things up, but > even if you have to make it a hidden option, I know it would be > invaluable to the ESX crowd. When you're running on a ZFS storage > base, having sync writes in NFS doesn't add any security, as ZFS is > handling all of that for us, and often with far more > performance/reliability. > I'm not sure what you are saying here. Are you assuming that ZFS won't lose data when the server crashes, even if it isn't getting the VOP_SYNC() for the file when the client assumes it is saved to stable storage (disk or SSD or ...)? (You say "security", but it sounds like you are referring to data reliability along the lines of "won't lose any file data if it crashes/reboots.) I don't know anything about ZFS, but I would think that, if you see a major performance improvement, that ZFS isn't committing stuff to logs so that data won't be lost. Maybe the ZFS folks can comment? (I don't remember seeing the details of what you change? If you sent a patch, sorry, but I've misplaced it.) > I think it would give a nice advantage to a FreeBSD ZFS/NFS solution. > It definitely makes a speed difference, even with a properly > configured ZIL. > > Would it be enough to have a big warning on the man page for the > switch that it breaks RFC compliance, to log that warning when it > happens, and to generally warn of dire consequences to anyone who > doesn't understand what they are doing? > Well, my concern is that the sysadmins won't realize that they can lose file data if the server crashes/reboots with this enabled. Which is what I believe your changes would do, if I understood it correctly? If the client is specifying the FILE_SYNC on each write, it is saying that it expects the data and metadata for the file being written to be saved to stable storage (so that it won't be lost due to a crash/reboot) before the server replies to that write rpc. (If you choose not to do that, file corruption etc can happen. Some environments wouldn't care, but the sysadmins need to know what they are doing w.r.t. this.) The NFS spec. writers chose not to make this optional (RFC1813 says "must" for this) and I suspect it was because they understood that sysadmins wouldn't be ready for the consequences. I think it's up to the "collective" whether or not something like this goes in the code, but I personally thing it's a risky idea. rick