Date: Tue, 25 Oct 2016 20:06:58 +0300 (MSK) From: Antony Uspensky <uspensky@x-art.ru> To: "Eugene M. Zheganin" <emz@norma.perm.ru> Cc: "stable@freebsd.org" <stable@freebsd.org> Subject: Re: zfs/raidz: seems like I'm failing with math Message-ID: <alpine.BSF.2.00.1610251912280.68217@gw-old.x-art.ru> In-Reply-To: <75ef50fa-0e0a-c576-c558-145ddcb32f0b@norma.perm.ru> References: <fa71cc53-83f3-2315-d047-36679700dd18@norma.perm.ru> <CAOtMX2hfWMoC5_aQCd7mS9zXF3qg=AZ70Z3Q9bGVoeY7eG0Rrg@mail.gmail.com> <75ef50fa-0e0a-c576-c558-145ddcb32f0b@norma.perm.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Oct 2016, Eugene M. Zheganin wrote: > Thanks ! It does explain it. But then again, on a pool that has been just > created, I check the properties of the root dataset (I'm posting all the > properties, just to display there's no child datasets or data on the pool): > > ===Cut=== > # zfs get all gamestop > NAME PROPERTY VALUE SOURCE > gamestop checksum on default > ===Cut=== > > Only 4.03T is available. Looks like it's the actual size, since it's zfs and > not zpool. But 960197124096 bytes * 5 / 1024^4 gives me 4.366 Tb, and not the > 4.03 T. Where did about 300 gigs go ? I'm really trying to understand, not to > catch some questionable logic or find errors. Checksums and zfs data structures - less then 8% of total space. Not too expensive. And do not confuse checksums (zfs level) and parity (zpool). But this is estimated available space for empty pool. Real allocated space for filled up pool will be a bit less then 4.03T due to padding - read https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1610251912280.68217>