From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 01:05:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16812202 for ; Wed, 23 Apr 2014 01:05:27 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5EEF12EF for ; Wed, 23 Apr 2014 01:05:26 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3N14HcZ000660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2014 18:04:17 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3N14Hdm000659; Tue, 22 Apr 2014 18:04:17 -0700 (PDT) (envelope-from jmg) Date: Tue, 22 Apr 2014 18:04:17 -0700 From: John-Mark Gurney To: Adam Vande More Subject: Re: Pointer to info on migrating from UFS2 -> ZFS? Message-ID: <20140423010417.GH43976@funkthat.com> Mail-Followup-To: Adam Vande More , David Wolfskill , Louis Kowolowski , hackers@freebsd.org References: <5355E9F9.5080401@freebsd.org> <63190425-672D-4A05-AAB0-B19A49EDB739@cryptomonkeys.org> <20140422222525.GR1321@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 22 Apr 2014 18:04:18 -0700 (PDT) Cc: Louis Kowolowski , hackers@freebsd.org, David Wolfskill X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 01:05:27 -0000 Adam Vande More wrote this message on Tue, Apr 22, 2014 at 19:50 -0500: > On Tue, Apr 22, 2014 at 5:25 PM, David Wolfskill wrote: > > > I appreciate the responses, but I seem to have failed to communicate at > > least a couple of fairly important aspects of what I'm trying to do. > > So.... > > > > On Mon, Apr 21, 2014 at 06:40:05PM -0700, Louis Kowolowski wrote: > > > I?d probably suggest a couple things: > > > * VirtualBox (or equiv) for setting up test environments that are easy > > to create and destroy. For all the beginning stuff I can think of, you > > should be able to do just fine with a virtual environment. VMs with a half > > dozen virtual disks that are 2G ea come in handy with playing with ZFS. > > > > I have existing hardware -- several instantiations of it, including a > > couple of test machines. I am trying to find out if the use of ZFS (vs. > > UFS2+SU) on the existing hardware will provide a performance advantage > > (and if so, how much, as switching from UFS2 to ZFS is going to be > > extremely painful). > > It's very difficult to make any detailed concise comment since we know > virtually nothing about your hw or workload. What do you need? More iops? > Then use a ZIL (maybe even a battery backed DDR drive) to increase writes, But that is only for sync writes, which are for things like fsync... ZFS write delays writes for vfs.zfs.txg.timeout seconds and combines them into transaction groups, so unless you're running a db that does fsync or an NFS server, a ZIL probably won't help you as much as you think it will... Obviously benchmark your use case w/ and w/o ZIL... > and lots of RAM and cache device to increase read speed. When I had this > setup, diskinfo run on VM's backed by ZVOL's would reflect SSD, not 7200 > spinning media speeds. > > Also things like transparent compression can help certain workloads > tremendously. If you're dealing with 99% text data by compressing the data > you effectively drastically lower the iops needed to work the data and > off-load the work to the CPU's which are obvious a lot faster than disk. > > There are also a lot of different RAID(z) qualities so care should be taken > when choosing layouts. Yes, it should be... remeber that raidz is closer to RAID3, than RAID5 in terms of IOPS, but doesn't suffer the read-modify-write issue that RAID5 has... So you won't necessarily get the same IOPS from a raidz config as you would from a hardware raid5 system... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."