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