From owner-freebsd-fs@FreeBSD.ORG Sun Sep 4 00:00:26 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 1E01F1065672 for ; Sun, 4 Sep 2011 00:00:26 +0000 (UTC) (envelope-from brodbd@uw.edu) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B3DEB8FC0C for ; Sun, 4 Sep 2011 00:00:06 +0000 (UTC) Received: by ewy1 with SMTP id 1so2266662ewy.13 for ; Sat, 03 Sep 2011 17:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.14.18 with SMTP id e18mr279125eba.47.1315094405542; Sat, 03 Sep 2011 17:00:05 -0700 (PDT) Received: by 10.213.22.210 with HTTP; Sat, 3 Sep 2011 17:00:05 -0700 (PDT) In-Reply-To: References: <14220705.747900.1315013770239.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 3 Sep 2011 17:00:05 -0700 Message-ID: From: David Brodbeck To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ZFSv28+NFSv4 poor file creation performance, "sync=disabled" has no effect 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, 04 Sep 2011 00:00:26 -0000 On Fri, Sep 2, 2011 at 6:36 PM, Rick Macklem wrote: > One post explained how disabling the ZIL can result in up to 5seconds worth > of changes being lost if/when the server crashes. (A lot can change on a > file > system in 5sec. The NFS protocol assumes all fs changes related to a file > creation are done before the server replies to the RPC. As such, disabling > the > ZIL does violate the protocol specs and means you are living dangerously.) > Yes, I'm aware of that. I chose to take that risk in my configuration because we frequently extract large tarballs, and performance with the default settings is not acceptable. Also, most other filesystems make no guarantees that data has been flushed to the platters, only that it's been sent to the disk hardware, so it really isn't a big increase in risk compared to our pre-ZFS setup. The sync=disabled parameter was, in my understanding, added as a per-filesystem way to achieve this risk/performance tradeoff, instead of zil_disable, which was system-wide. I posted the question because I'm not seeing any changes when I use sync=disabled. This is a bit of a show-stopper for us because performance with full syncing is not acceptable. I agree that it's not ideal, but we don't have the extra drive bays to add SSDs at this point; also it seems like people have had a lot of problems with SSDs and FreeBSD, so I'd prefer for the technology to mature a bit before I risk my entire pool by putting a ZIL on one. -- David Brodbeck System Administrator, Linguistics University of Washington