More redundancy below...
Torrey McMahon wrote:
Phillip Fiedler wrote:
Thanks for the input. So, I'm trying to meld the two replies and come
up with a direction for my case and maybe a "rule of thumb" that I can
use in the future (i.e., near future until new features come out in
zfs) when I have external storage arrays that have built in RAID.
At the moment, I'm hearing that using h/w raid under my zfs may be
better for some workloads and the h/w hot spare would be nice to have
across multiple raid groups, but the checksum capabilities in zfs are
basically nullified with single/multiple h/w lun's resulting in
"reduced protection." Therefore, it sounds like I should be strongly
leaning towards not using the hardware raid in external disk arrays
and use them like a JBOD.
The bit ...
the checksum capabilities in zfs are basically nullified with
single/multiple h/w lun's resulting in "reduced protection."
is not accurate. With one large LUN, then yes, you can only detect
errors. With multiple LUNs in a mirror or RAIDZ{2} then you can correct
errors.
You can also add redundancy with ZFS filesystem copies parameter. This is
similar to, but not the same as mirroring.
The big reasons for continuing to use hw raid is speed, in some cases,
and heterogeneous environments where you can't farm out non-raid
protected LUNs and raid protected LUNs from the same storage array. In
some cases the array will require a raid protection setting, like the
99x0, before you can even start farming out storage.
Yes. ZFS data protection builds on top of this. You always gain a benefit
when the data protection is done as close to the application as possible -- as
opposed to implementing the data protection as close to the storage as possible.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
