From owner-freebsd-questions@FreeBSD.ORG Sat Aug 2 10:25:05 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 D6890E88 for ; Sat, 2 Aug 2014 10:25:05 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 87E032F2F for ; Sat, 2 Aug 2014 10:25:05 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s72AP3Hp016258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 2 Aug 2014 04:25:03 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s72AP2FG016254; Sat, 2 Aug 2014 04:25:02 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 2 Aug 2014 04:25:02 -0600 (MDT) From: Warren Block To: Scott Bennett Subject: Re: gvinum raid5 vs. ZFS raidz In-Reply-To: <201408020621.s726LsiA024208@sdf.org> Message-ID: References: <201408020621.s726LsiA024208@sdf.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 02 Aug 2014 04:25:03 -0600 (MDT) 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 10:25:05 -0000 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.