Date: Thu, 7 Aug 2014 12:36:56 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: Scott Bennett <bennett@sdf.org> Cc: freebsd@qeng-ho.org, FreeBSD questions <freebsd-questions@freebsd.org> Subject: Re: gvinum raid5 vs. ZFS raidz Message-ID: <alpine.BSF.2.11.1408071226020.64214@mail.fig.ol.no> In-Reply-To: <201408070936.s779akMv017524@sdf.org> References: <201408020621.s726LsiA024208@sdf.org> <alpine.BSF.2.11.1408020356250.1128@wonkity.com> <53DCDBE8.8060704@qeng-ho.org> <201408060556.s765uKJA026937@sdf.org> <53E1FF5F.1050500@qeng-ho.org> <201408070831.s778VhJc015365@sdf.org> <alpine.BSF.2.11.1408071034510.64214@mail.fig.ol.no> <201408070936.s779akMv017524@sdf.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Aug 2014 04:36-0500, Scott Bennett wrote: > Trond Endrestøl <Trond.Endrestol@fagskolen.gjovik.no> wrote: > > On Thu, 7 Aug 2014 03:31-0500, Scott Bennett wrote: > > > Arthur Chance <freebsd@qeng-ho.org> wrote: > > > > On 06/08/2014 06:56, Scott Bennett wrote: > > > > > Arthur Chance <freebsd@qeng-ho.org> wrote: > > > > >> > > > > >> [stuff deleted --SB] > > > > > 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. > > > > > > > > I'm not a file system guru, but my (high level) understanding is as > > > > follows. Corrections from anyone more knowledgeable welcome. > > > > > > > > 1. UFS and ZFS both use tree structures to represent files, with the > > > > data stored at the leaves and bookkeeping stored in the higher nodes. > > > > Therefore the overhead scales as the log of the data size, which is a > > > > negligible fraction for any sufficiently large amount of data. > > > > > > > > 2. UFS doesn't have data checksums, it relies purely on the hardware > > > > checksums. (This is the area I'm least certain of.) > > > > > > What hardware checksums are there? I wasn't aware that this sort of > > > hardware kept any. > > > > To quote http://en.wikipedia.org/wiki/Disk_sector: > > > > In disk drives, each physical sector is made up of three basic parts, > > the sector header, the data area and the error-correcting code (ECC). > > That's interesting, and I know it was true in the days of minicomputers. > However, it appears to be out of date, based upon 1) the observed fact that > corrupted data *do* get recorded onto today's PC-style disk drives with no > indication that an error has occurred, no parity bits are present in the > processor chips, memory cards, motherboards, PATA/SATA/SCSI/etc. controllers, > nor 2) the disk drives themselves, as confirmed by the technical support guy > I spoke with about it at Seagate/Samsung recently. That guy said that there > is *no parity-checking* of data written to/read from the disks and that some > silent errors are now considered to be "normal" on disks whose capacities > exceed 1 TB. I guess I stand corrected. It's been some years since I had any CS/CE education, and maybe my professor's knowledge were also a bit dated back then (1999-2002). However, some, if not all, enterprise graded disks uses 520 bytes blocks, giving 8 bytes extra compared to the usual 512 bytes blocks, possibly to be used for ECC, etc. Though, as proved above, I can be equally wrong about the ECC used in enterprise graded disks. It seems modern day consumer electronics are being manufactured way too brittle. :-/ -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-questions@FreeBSD.ORG Thu Aug 7 11:07:23 2014 Return-Path: <owner-freebsd-questions@FreeBSD.ORG> 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 D93FF41B for <freebsd-questions@freebsd.org>; Thu, 7 Aug 2014 11:07:23 +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 B9D052764 for <freebsd-questions@freebsd.org>; Thu, 7 Aug 2014 11:07:22 +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 s77B6K9r013235 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 7 Aug 2014 11:06:20 GMT Received: (from bennett@localhost) by sdf.org (8.14.8/8.12.8/Submit) id s77B6JCI005742; Thu, 7 Aug 2014 06:06:19 -0500 (CDT) From: Scott Bennett <bennett@sdf.org> Message-Id: <201408071106.s77B6JCI005742@sdf.org> Date: Thu, 07 Aug 2014 06:06:19 -0500 To: Trond.Endrestol@fagskolen.gjovik.no Subject: Re: gvinum raid5 vs. ZFS raidz References: <201408020621.s726LsiA024208@sdf.org> <alpine.BSF.2.11.1408020356250.1128@wonkity.com> <53DCDBE8.8060704@qeng-ho.org> <201408060556.s765uKJA026937@sdf.org> <53E1FF5F.1050500@qeng-ho.org> <201408070831.s778VhJc015365@sdf.org> <alpine.BSF.2.11.1408071034510.64214@mail.fig.ol.no> <201408070936.s779akMv017524@sdf.org> <alpine.BSF.2.11.1408071226020.64214@mail.fig.ol.no> In-Reply-To: <alpine.BSF.2.11.1408071226020.64214@mail.fig.ol.no> 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: freebsd@qeng-ho.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions <freebsd-questions.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>; List-Post: <mailto:freebsd-questions@freebsd.org> List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 07 Aug 2014 11:07:23 -0000 Trond Endrest?l <Trond.Endrestol@fagskolen.gjovik.no> wrote: > On Thu, 7 Aug 2014 04:36-0500, Scott Bennett wrote: > > Trond Endrest?l <Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > On Thu, 7 Aug 2014 03:31-0500, Scott Bennett wrote: > > > > Arthur Chance <freebsd@qeng-ho.org> wrote: > > > > > On 06/08/2014 06:56, Scott Bennett wrote: > > > > > > Arthur Chance <freebsd@qeng-ho.org> wrote: > > > > > >> > > > > > >> [stuff deleted --SB] > > > > > > 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. > > > > > > > > > > I'm not a file system guru, but my (high level) understanding is as > > > > > follows. Corrections from anyone more knowledgeable welcome. > > > > > > > > > > 1. UFS and ZFS both use tree structures to represent files, with the > > > > > data stored at the leaves and bookkeeping stored in the higher nodes. > > > > > Therefore the overhead scales as the log of the data size, which is a > > > > > negligible fraction for any sufficiently large amount of data. > > > > > > > > > > 2. UFS doesn't have data checksums, it relies purely on the hardware > > > > > checksums. (This is the area I'm least certain of.) > > > > > > > > What hardware checksums are there? I wasn't aware that this sort of > > > > hardware kept any. > > > > > > To quote http://en.wikipedia.org/wiki/Disk_sector: > > > > > > In disk drives, each physical sector is made up of three basic parts, > > > the sector header, the data area and the error-correcting code (ECC). > > > > That's interesting, and I know it was true in the days of minicomputers. > > However, it appears to be out of date, based upon 1) the observed fact that > > corrupted data *do* get recorded onto today's PC-style disk drives with no > > indication that an error has occurred, no parity bits are present in the > > processor chips, memory cards, motherboards, PATA/SATA/SCSI/etc. controllers, > > nor 2) the disk drives themselves, as confirmed by the technical support guy > > I spoke with about it at Seagate/Samsung recently. That guy said that there > > is *no parity-checking* of data written to/read from the disks and that some > > silent errors are now considered to be "normal" on disks whose capacities > > exceed 1 TB. > > I guess I stand corrected. It's been some years since I had any CS/CE > education, and maybe my professor's knowledge were also a bit dated > back then (1999-2002). > > However, some, if not all, enterprise graded disks uses 520 bytes > blocks, giving 8 bytes extra compared to the usual 512 bytes blocks, > possibly to be used for ECC, etc. Even just as parity bits, those would amount to only one bit per eight bytes, which seems inadequate. OTOH, the 520 bytes thing is tickling something in my memory that I can't quite seem to recover, and I don't know (or can't remember) what else those eight bytes might be used for. In any case, at the time I spoke with the guy at Seagate/Samsung, I was unaware of the server grade vs. non-server grade distinction, so I didn't know to ask him anything about whether silent errors should be accepted as "normal" for the server grade of disks. > > Though, as proved above, I can be equally wrong about the ECC used in > enterprise graded disks. As just noted above, I can't comment about server/enterprise grades of disks either. However, I do not that many server motherboards can use, or even require, ECC memory. Whether the parity information from the ECC memory is also reflected in extra data bus lines in the CPU, I/O controllers, or peripheral devices of any kind is another matter. > > It seems modern day consumer electronics are being manufactured way > too brittle. :-/ > I agree completely. Scott Bennett, Comm. ASMELG, CFIAG P.O. Box 772 DeKalb, Illinois 60115 ********************************************************************** * 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 * **********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1408071226020.64214>