gvinum raid5 vs. ZFS raidz

Trond Endrestøl Trond.Endrestol at fagskolen.gjovik.no
Thu Aug 7 10:37:02 UTC 2014


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.

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.      |
+-------------------------------+------------------------------------+


More information about the freebsd-questions mailing list