On Tue, Dec 30, 2014 at 1:05 PM, J. Roeleveld <jo...@antarean.org> wrote: > > I could do with a hardware controller which can be used to off-load all the > heavy lifting for the RAIDZ-calculations away from the CPU. And if the stuff > for the deduplication could also be done that way? >
The CPU is the least of the reasons why ZFS/btrfs will outperform traditional RAID. Most of the benefits come from avoiding disk operations. If you write 1 byte to the middle of a file ext4 will overwrite one block in-place, and md will read a stripe and then rewrite the stripe. If you write 1 byte to the middle of a file on btrfs (and likely zfs) it will just write 1 byte to the metadata and bunch it up with a bunch of other writes, likely overwriting an entire stripe at once so that there is no need to read the strip first. If you copy a file in btrfs it will just create a reflink and it is a metadata-only change, etc. If you scrub your array the filesystem knows what blocks are in use and only those get checked, and if the filesystem has checksums at the block level it can do the scrub asynchronously which impacts reads less, etc. I'm sure that CPU optimizations count for something, but avoiding disk IO is going to have a much larger impact, especially with spinning disks. -- Rich
