On Oct 24, 2006, at 2:46 PM, Richard Elling - PAE wrote:
Pedantic question, what would this gain us other than better data
retention?
Space and (especially?) performance would be worse with RAID-Z+1
than 2-way mirrors.
You answered your own question, it would gain the user better data
retention :)
The space tradeoff is an obvious side effect and unavoidable. For
situations where this is not an overriding issue, it just isn't an
issue. I don't believe performance would be adversely impacted to a
practical degree, though.
A "dumb" ZFS mirror strategy in this case would just copy reads and
writes to and from the vdevs below it, OR pre-package the writes
itself with compression and checksums and send that data below to the
raidz's to be stored (which would probably be more problematic to
implement in the zfs code).
With the latter, checksums and compression would be done only once
(at the mirror level) and not done by each of the n number of
underlying vdevs.
So, a little ascii art to summarize:
1) The probably-easiest-to-implement approach:
[app]
|
[zfs volume]
|
[vdev mirror] <-- passes thru read/write ops,
regulates recordsize. It's mainly "dumb"
|
[raidz vdev]-- |--[raidz vdev]... <-- each vdev generates cksums,
compression per normal
| | | | | | | |
[phys devs] [phys devs]
2) The less-CPU-but-more-convoluted approach:
[app]
|
[zfs volume]
|
[vdev mirror] <-- generates cksums, compression,
regulates recordsize
|
[raidz vdev]-- |--[raidz vdev]... <-- each vdev just stores data
as it is passed in from above
| | | | | | | |
[phys devs] [phys devs]
Any of those two would be quite handy in the environment where you
want to mirror data between, say, JBODs and retention is the primary
goal.
/dale
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
