Hacker News Reader

Comment by louwrentius | Hacker News Reader

I'm sorry but I don't think I follow you. Mirroring can never achieve the space / redundancy efficiency of parity raid, I don't see how the above works.

View on HN

It looks like he's trying to say: in an array of N >= 2 drives, "BTRFS RAID 1" will still only choose 2 disks to replicate a file to. It's just 2 different ones for every file.

Well, not every file, but you see the point.

If that's the case, this has the advantage of having a subset of files recoverable even after >1 disk failure. Unlike RAID 5.

On the flip side: read speed is limited to at most 2 concurrent disks. Unlike RAID 5, where it's N-1. But that's theoretical, what's the reality on read speeds in RAID 5?

Anyway, if that's true, that would be a really weird name. Why didn't they call that "BTRFS RAID 5"? A look at the docs doesn't make this clear to me at all. I'm not sure what to believe...

I was not even aware of this possibility, thanks for explaining it to me.

The concept fills with me with absolute horror though. Losing a part of my files is as bad as losing everything.

The performance benefit with larger files of RAID1 vs RAID5/6 can be very 'substantial'. Even my old 18 TB NAS could achieve 1+ GB/s on sequential reads.

RAID isn't backup. Losing some of your files instead of all your files means you have access to some of the files during the restore window. And your restore might be quicker?

But how do you even fire up an Oracle database with some of the dbf files missing? And I can't think of any other application (other than maybe a document storage system) that would be useful with some of the files missing.

You don't. You rsync the missing files over and skip the data that is already present, saving time.

RAID5/6+ is only as fast as your slowest disk, and seek times are no better. In most respects, mirroring gets you better performance, and for most drive configurations, is more reliable than RAID5. Massive throughput on single files one at a time is not interesting to most people with big storage requirements.

I currently run RAID6 (raidz2) across 10 drives. But I'll be moving to RAID10 before long. Whether using zfs or not, depends on btrfs stability.

RAID5/6 is only as fast as the slowes disk regarding ZFS yes if you talk about random IOPS. BTRFS performance I haven't measured yet.

RAID5/6 random IOPS can be quite good or as you can expect if you use MDADM.

The best solution seems to be tons of RAM for caching and ZFS with SSD SLOG if you need reliable and fast sync writes. But with ZFS, performance comes second over reliability.

As you said yourself, volume sizes aren't exactly the problem anymore ie there is tons of space to store bits these days.

Raid rebuilds take way too long for modern volume sizes.

Raid rebuilds take so long that the likelihood of losing a second drive before completion is very high.

The safety you generally want is redundant copies of checksummed data and metadata blocks.

Btrfs allows you to choose the number of copies of data or metadata separately.

Talking about RAID in the context of btrfs and zfs generally seems to confuse people as it brings in the old expectations and understandings they worked so hard at figuring out for the RAID era.

Rebuilds on ZFS and BTRFS are quite reasonable because most of the time only the data itself is rebuild, not the entire drive as with old-fashioned solutions.

Rebuilds depend on drive size, not array size.

Tripple-parity as part of ZFS allows you to create even larger VDEVS while keeping the risks manageable. Interesting for low-performance archiving solutions.

ZFS has ditto blocks, too. Surely having parity striping and ditto blocks both is better than just ditto blocks pretending to be parity striping.

Reply on news.ycombinator.com