gvinum raid5 vs. ZFS raidz

Scott Bennett bennett at sdf.org
Thu Aug 7 11:07:23 UTC 2014


Trond Endrest?l <Trond.Endrestol at fagskolen.gjovik.no> wrote:
> On Thu, 7 Aug 2014 04:36-0500, Scott Bennett wrote:
> > Trond Endrest?l <Trond.Endrestol at fagskolen.gjovik.no> wrote:
> > > On Thu, 7 Aug 2014 03:31-0500, Scott Bennett wrote:
> > > > Arthur Chance <freebsd at qeng-ho.org> wrote:
> > > > > On 06/08/2014 06:56, Scott Bennett wrote:
> > > > > > Arthur Chance <freebsd at 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         *
**********************************************************************


More information about the freebsd-questions mailing list