From owner-freebsd-questions@FreeBSD.ORG Sat Aug 2 12:39:15 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 7E75F5FD for ; Sat, 2 Aug 2014 12:39:15 +0000 (UTC) Received: from blue.qeng-ho.org (blue.qeng-ho.org [217.155.128.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F17862A81 for ; Sat, 2 Aug 2014 12:39:14 +0000 (UTC) Received: from fileserver.home.qeng-ho.org (localhost [127.0.0.1]) by fileserver.home.qeng-ho.org (8.14.7/8.14.5) with ESMTP id s72Cd4Ar004013; Sat, 2 Aug 2014 13:39:05 +0100 (BST) (envelope-from freebsd@qeng-ho.org) Message-ID: <53DCDBE8.8060704@qeng-ho.org> Date: Sat, 02 Aug 2014 13:39:04 +0100 From: Arthur Chance User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warren Block , Scott Bennett Subject: Re: gvinum raid5 vs. ZFS raidz References: <201408020621.s726LsiA024208@sdf.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org, Paul Kraus 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: Sat, 02 Aug 2014 12:39:15 -0000 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.