Gregory Shaw wrote:
Yes, but the idea of using software raid on a large server doesn't make
sense in modern systems. If you've got a large database server that
runs a large oracle instance, using CPU cycles for RAID is counter
productive. Add to that the need to manage the hardware directly (drive
microcode, drive brownouts/restarts, etc.) and the idea of using JBOD in
modern systems starts to lose value in a big way.
You will detect any corruption when doing a scrub. It's not end-to-end,
but it's no worse than today with VxVM.
Yes, but we're trying to be better than VxVM. The end-to-end guarantee
that ZFS offers is one of, if not the, primary attractor to using it in
the first place.
CPU cycles are cheap these days. In the era of sub-1ghz single core/chip
systems, yes, those XOR calculations for software RAID were expensive.
Now, not so much I think as that problem has been solved by brute force.
When using ZFS in a storage network, I'm envisioning the arrays being a
hybrid between what a JBOD is and what a full-fledge hardware RAID5 with
tons o' cache is.
As far as I'm concerned, the traditional RAID features on an array do
not offer me much when using those LUNs with ZFS. I lose that
end-to-end. But the arrays are still useful from a performance
perspective because of their caching, LUN management, and FC-related
abilities which is something a JBOD largely lacks.
/dale
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
