From owner-freebsd-questions@FreeBSD.ORG Wed Aug 6 05:56:29 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB39E5C7 for ; Wed, 6 Aug 2014 05:56:29 +0000 (UTC) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.sdf.org", Issuer "SDF.ORG" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A1F8A23FA for ; Wed, 6 Aug 2014 05:56:29 +0000 (UTC) Received: from sdf.org (IDENT:bennett@sdf.lonestar.org [192.94.73.15]) by sdf.lonestar.org (8.14.8/8.14.5) with ESMTP id s765uKc5002335 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Wed, 6 Aug 2014 05:56:21 GMT Received: (from bennett@localhost) by sdf.org (8.14.8/8.12.8/Submit) id s765uKJA026937; Wed, 6 Aug 2014 00:56:20 -0500 (CDT) From: Scott Bennett Message-Id: <201408060556.s765uKJA026937@sdf.org> Date: Wed, 06 Aug 2014 00:56:20 -0500 To: wblock@wonkity.com, freebsd@qeng-ho.org Subject: Re: gvinum raid5 vs. ZFS raidz References: <201408020621.s726LsiA024208@sdf.org> <53DCDBE8.8060704@qeng-ho.org> In-Reply-To: <53DCDBE8.8060704@qeng-ho.org> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: paul@kraus-haus.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 05:56:30 -0000 Arthur Chance wrote: > On 02/08/2014 11:25, Warren Block wrote: > > On Sat, 2 Aug 2014, Scott Bennett wrote: > >> On Tue, 29 Jul 2014 12:01:36 -0400 Paul Kraus > > > >>> ZFS parity is handled slightly differently than for traditional > >>> raid-5 (as well as the striping of data / parity blocks). So you > >>> cannot just count on loosing 1, 2, or 3 drives worth of space to > >>> parity. See Matt Ahren?s Blog entry here > >>> http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/ for > >>> (probably) more data on this than you want :-) And here > >>> https://docs.google.com/a/delphix.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT689wTjHv6CGVElrPqTA0w_ZY/edit?pli=1#gid=2126998674 > >>> is his spreadsheet that relates space lost due to parity to number of > >>> drives in raidz vdev and data block size (yes, the amount of space > >>> lost to parity caries with data block, not configured filesystem > >>> block size!). There is a separate tab for each of RAIDz1, RAIDz2, and > >>> RAIDz3. > >>> > >> Anyway, using lynx(1), it is very hard to make any sense of the > >> spreadsheet. > > > > Even with a graphic browser, let's say that spreadsheet is not a paragon > > of clarity. It's not clear what "block size in sectors" means in that > > context. Filesystem blocks, presumably, but are sectors physical or > > virtual disk blocks, 512 or 4K? What is that number when using a > > standard configuration of a disk with 4K sectors and ashift=12? It > > could be 1, or 8, or maybe something else. > > > > As I read it, RAIDZ2 with five disks uses somewhere between 67% and 40% > > of the data space for redundancy. The first seems unlikely, but I can't > > tell. Better labels or rearrangement would help. > > > > A second chart with no labels at all follows the first. It has only the > > power-of-two values in the "block size in sectors" column. A > > restatement of the first one... but it's not clear why. > > > > My previous understanding was that RAIDZ2 with five disks would leave > > 60% of the capacity for data. > > Quite right. If you have N disks in a RAIDZx configuration, the fraction > used for data is (N-x)/N and the fraction for parity is x/N. There's > always overhead for the file system bookkeeping of course, but that's > not specific to ZFS or RAID. I wonder if what varies is the amount of space taken up by the checksums. If there's a checksum for each block, then the block size would change the fraction of the space lost to checksums, and the parity for the checksums would thus also change. Enough to matter? Maybe. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************