On Wed, Jan 11, 2012 at 9:16 AM, Jim Klimov <jimkli...@cos.ru> wrote:
> I've recently had a sort of an opposite thought: yes,
> ZFS redundancy is good - but also expensive in terms
> of raw disk space. This is especially bad for hardware
> space-constrained systems like laptops and home-NASes,
> where doubling the number of HDDs (for mirrors) or
> adding tens of percent of storage for raidZ is often
> not practical for whatever reason.

Redundancy through RAID-Z and mirroring is expensive for home systems
and laptops, but mostly due to the cost of SATA/SAS ports, not the
cost of the drives.  The drives are cheap, but getting an extra disk
in a laptop is either impossible or expensive.  But that doesn't mean
you can't mirror slices or use ditto blocks.  For laptops just use
ditto blocks and either zfs send or external mirror that you

> Current ZFS checksums allow us to detect errors, but
> in order for recovery to actually work, there should be
> a redundant copy and/or parity block available and valid.
> Hence the question: why not put ECC info into ZFS blocks?

RAID-Zn *is* an error correction system.  But what you are asking for
is a same-device error correction method that costs less than ditto
blocks, with error correction data baked into the blkptr_t.  Are there
enough free bits left in the block pointer for error correction codes
for large blocks?  (128KB blocks, but eventually ZFS needs to support
even larger blocks, so keep that in mind.)  My guess is: no.  Error
correction data might have to get stored elsewhere.

I don't find this terribly attractive, but maybe I'm just not looking
at it the right way.  Perhaps there is a killer enterprise feature for
ECC here: stretching MTTDL in the face of a device failure in a mirror
or raid-z configuration (but if failures are typically of whole drives
rather than individual blocks, then this wouldn't help).  But without
a good answer for where to store the ECC for the largest blocks, I
don't see this happening.

zfs-discuss mailing list

Reply via email to