From owner-freebsd-questions@freebsd.org Fri Sep 25 02:49:41 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73F2CA09DFA for ; Fri, 25 Sep 2015 02:49:41 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35B97199B for ; Fri, 25 Sep 2015 02:49:40 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by qkdw123 with SMTP id w123so37630439qkd.0 for ; Thu, 24 Sep 2015 19:49:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1bTHte7619r9mi0lri01mfb8Pkkj2qMZ1crc86CZGfE=; b=PBm23MvbwGXLXM892pQn2X8aMxRuxeK65VIFZ//KRVIQoqoLahzb7VHI8plutYZJLj kEzxy6HYngpZseksHlNrBpUHX01qepVz5MWPcc6FX8Pz60Ikh4UmnFmwEWEA4kAK8NB1 /KSEaLW/+taapXLjldZRxIhbM+93ubrNhA3Q6RifK2WYp9+yzQP6sJ/NpRoK1hSFUgqp WORNv5E5vgjI1/9PsLhVbeBVQjeNkq7H2BSPOJj/4B8M5nz/XNJHKLjEcrtcmlqx056J kCHngBWfAgqPVAdaPlY+3W2tmTOWlD7NpkvDGz60l9ATEVu3Z2vMZclYUPthiKZoBxnJ GBJg== X-Gm-Message-State: ALoCoQl7yAzwDGnHzFZrCxG7im5NKfbmSptSjSQ9BAAh2vSRqVyYEw4q2ivCLY8YQJd6yMyeefKn X-Received: by 10.55.23.9 with SMTP id i9mr3586384qkh.22.1443149373913; Thu, 24 Sep 2015 19:49:33 -0700 (PDT) Received: from [192.168.2.138] (pool-100-4-179-8.albyny.fios.verizon.net. [100.4.179.8]) by smtp.gmail.com with ESMTPSA id f86sm629146qkf.0.2015.09.24.19.49.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Sep 2015 19:49:32 -0700 (PDT) Subject: Re: sync vs async vs zfs Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Paul Kraus In-Reply-To: <5604ABF0.3060007@sneakertech.com> Date: Thu, 24 Sep 2015 22:49:29 -0400 Cc: FreeBSD questions Content-Transfer-Encoding: quoted-printable Message-Id: <09CBDA9F-28FD-4579-A648-E6D2F5660A91@kraus-haus.org> References: <56042774.6070404@sneakertech.com> <98BFE313-523F-4A2C-82BB-8683466068FB@kraus-haus.org> <560462C4.6030106@sneakertech.com> <5604ABF0.3060007@sneakertech.com> To: Quartz X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 02:49:41 -0000 On Sep 24, 2015, at 22:05, Quartz wrote: >> I expect that system utilities like cp and tar do not do sync writes. >> sync writes are supposed to be a special case, used only when needed. >> I run into them with VBox writing to<>.vmdk files. >=20 > NFS forces sync though, doesn't it? What if you're cp-ing to a mounted = share? I'm not sure I totally understand how all this interacts. Reading the NFS ver 3 RFC (1813, available here: = https://tools.ietf.org/html/rfc1813, look for the descriptions of the = WRITE and COMMIT procedures), it looks like NFS ver 2 was sync only, = while ver 3 added the ability (at the protocol layer) to require sync = data, sync data + metadata, or async behavior. =46rom some Linux NFS = notes I found it appears that the default Linux behavior is sync, but = you can disable sync on the server side (as you can with ZFS) in which = case the NFS server does not follow the protocol specification. =46rom the FreeBSD man page options for mount_nfs: wcommitsize=3D Set the maximum pending write commit size to the = speci- fied value. This determines the maximum amount of = pend- ing write data that the NFS client is willing to = cache for each file. This implies that the FreeBSD NFS client fully implements the ver 3 = protocol which permits the client to cache data until an fsync call is = made or the amount of data in the client cache reaches =93wcommitsize=94. = Essentially, async behavior. It does not look like (from reading the exports man page) you can = disable handling of sync data, sync data + metadata, or async on the NFS = server side. In other words, the FreeBSD NFS server does what the client = instructs it, as it should to comply with the NFS Ver 3 specification in = the RFC. >>> 2) Async doesn't really care how your pool is constructed, and a >>> SLOG is really the only thing that seriously makes a difference for >>> sync, correct? >>=20 >> Not quite true. Once you get through the ARC the configuration of the >> zpool _will_ matter to performance. >=20 > Maybe I worded that badly. What I meant was that whereas sync write = performance is strongly affected by a SLOG, async writes have no special = considerations of their own that don't also affect sync, right? Correct. Any configuration change that effects async performance will = effect sync performance as well. While the ZIL/SLOG can effect sync = performance, they are not involved in async writer operations at all, so = cannot have nay effect on sync writes. Although, I suppose you _could_ say that an increase in the amount of = RAM available for the ARC may increase async write performance, such an = increase in ARC would have little to no effect on sync writes. While = sync writes _do_ go through the ARC, the ZIL/SLOG insulates the App = trying to write the data from that. -- Paul Kraus paul@kraus-haus.org