From owner-freebsd-fs@FreeBSD.ORG Thu May 12 23:02:53 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 087D3106566B for ; Thu, 12 May 2011 23:02:53 +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 BC2FF8FC14 for ; Thu, 12 May 2011 23:02:52 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAI9mzE2DaFvO/2dsb2JhbACEVqIaiHCuNpEYgSuDY4EHBI98jwU X-IronPort-AV: E=Sophos;i="4.64,361,1301889600"; d="scan'208";a="124562715" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 12 May 2011 19:02:51 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C4EDE793A7; Thu, 12 May 2011 19:02:51 -0400 (EDT) Date: Thu, 12 May 2011 19:02:51 -0400 (EDT) From: Rick Macklem To: Bob Friesenhahn Message-ID: <1700693186.266759.1305241371736.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.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: How to enable cache and logs. 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: Thu, 12 May 2011 23:02:53 -0000 > On Wed, 11 May 2011, Jeremy Chadwick wrote: > > > > Bob, please correct me if I'm wrong, but as I understand it a log > > device > > (ZIL) effectively limits the overall write speed of the pool itself. > > Consumer-level SSDs do not have extremely high write performance > > (and it > > gets worse without TRIM; again a 70% decrease in write speed in some > > cases). > > It is certainly a factor. However, large block writes (something like > 128K, I don't remember exactly) bypass the dedicated log device and > instead are written to the main store (with only a reference being > added to the dedicated device). The reason this is done is for the > exact reason you point out. The SSD has a very fast seek and zero > rotational latency but being a singular resource it suffers from > bandwidth limitations. The main store usually suffers from > multi-millisecond seeks and rotational latency but offers linearly > scalable and substantial write performance for larger writes. > > Matt Ahrens has described this a few times on the zfs-discuss list and > there is mention of it on slide 15 of the presentation found at > "http://www.slideshare.net/edigit/zfs-presentation". > > The large write feature of the ZIL is a reason why we should > appreciate modern NFS's large-write capability and avoid anchient NFS. > The size of a write for the new FreeBSD NFS server is limited to MAX_BSIZE. It is currently 64K, but I would like to see it much larger. I am going to try increasing MAX_BSIZE soon, to see what happens. This sounds like another good reason to increase it. However, a client chooses what size to use, up to the server`s limit (and, again, MAX_BSIZE for the FreeBSD client). rick