Hacker News new | ask | show | jobs
by cnvogel 4796 days ago
I've read a little bit of the material, but I don't get the feeling that they looked beyond block-level RAID5/6 (which btrfs/raid5, as far as I understand, is not).

[1] mentions that RAID5 never checks parity on read, which is not an issue with ZFS/zpool (and, I think, the proposed BTRFS/raid5) because they verify all read blocks' check sum. Also the creeping multiplication of bit-errors on parity rebuild is a non issue because of this. [2] only mentions ZFS, but attributes copy-on-write as the remedy against distribition of bad data over the RAID volume.

[1]: http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt

[2]: http://www.miracleas.com/BAARF/Why_RAID5_is_bad_news.pdf

And, yes, I see this silent corruption problem, and the inabilty to identify the "wrong" drive in case of parity mismatch as a big deficit of block-level RAIDs, and I share their view on the abysmally bad performance of some degraded/rebuilding arrays. But that is mainly what the filesystem-integrated redundancy mechanism try to address with their "blatant layering violation".

1 comments

Yeah, I don't think they cover raidz or raidz2. raidz is not exactly raid5, in the classic sense, because as you mention zfs does checksum verification.

I wasn't sure what btrfs (or the parent) meant by 'raid5'. I think zfs was wise to call it something else.