Richard Elling - PAE wrote:
Torrey McMahon wrote:
Raid calculations take CPU time but I haven't seen numbers on ZFS
usage. SVM is known for using a fair bit of CPU when performing R5
calculations and I'm sure other OS have the same issue. EMC used to go
around saying that offloading raid calculations to their storage
arrays would increase application performance because you would free
up CPU time to do other stuff. The "EMC effect" is how they used to
market it.
In all modern processors, and most ancient processors, XOR takes 1 CPU
cycle and is easily pipelined. Getting the data from the disk to the
registers
takes thousands or hundreds of thousands of CPU cycles. You will more
likely
feel the latency of the read-modify-write for RAID-5 than the CPU time
needed
for XOR. ZFS avoids the read-modify-write, but does compression, so it is
possible that a few more CPU cycles will be used. But it should still be a
big win because CPU cycles are less expensive than disk I/O. Meanwhile, I
think we're all looking for good data on this.
-- richard
I believe the true answer is (wait for it...) It Depends(TM) on what you're
limited on. If your system under your load is CPU constrained, ZFS calculating
the RAIDZ parity (and checksum) is going to hurt; if you are IO constrained
then having the otherwise idle CPU do (which is, of course, more than just an
XOR instruction, but we all know that) the work may help. The ZFS design
center of mostly-idle CPUs is not always accurate, although most customers
don't dare push the system to 100% utilization. It's when you _do_ hit that
point, or when the extra overhead unexpectedly makes you hit or go beyond that
point that things can get interesting quickly.
- Pete
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
