zfs on gmirror slice

[Emil Mikulic]

On Wed, Sep 02, 2009 at 10:27:40AM +0200, Mark Stapper wrote:
> Emil Mikulic wrote:
> > As Thomas Backman pointed out, this means you won't get self-healing.
> >   
> self-healing sounds very nice, but with mirrorring you have data on two
> discs, so in that case there no "healing" involved, it's just
> checksumming and reading the non-corrupted copy.

This won't work through gmirror because ZFS sees the mirror as a single
disk.

When it gets corrupt data, it has no way of signalling the gmirror layer
to try reading the other disk(s) in the mirror.  It's simply stuck with
the corrupt data.

Whereas with mirroring done by ZFS itself, it -can- try the other disks.
And "self-healing" is where it writes the correct data back to the
damaged disk on the fly.  That's pretty cool.

> From the gmirror manpage: "All operations like failure detection, stale
> component detection, rebuild of stale components, etc. are also done
> automatically."
> This would indicate the same functionality, with a much less fancy name.

Sorry, but no.  ZFS can do some much fancier things if you let it manage
the disks directly, e.g.:

- it can detect disks returning bad data (because it has checksums)
  whereas gmirror's "failure detection" requires the disk to return
  errors or stop responding entirely

- rebuild of stale components ("resilver") is proportional to the
  amount of data stored rather than the full capacity of the disks being
  used.  i.e. ZFS won't rebuild the free space in the filesystem.

> gmirror is fast though. I've even heard it's faster than software
> RAID1/ataraid. (not confirmed).

gmirror -is- software raid.  ataraid is really broken based on my
reading of these lists, I wouldn't trust my data to it.

> Even if this is true, running zfs on top of gmirror probably isn't
> faster then running zfs with a mirrored pool.

Maybe you wouldn't see a speed difference, but there's a significant
difference in features and reliability.

--Emil