On 2015-10-05 07:16, Lionel Bouton wrote:
Part of this is because BTRFS's built-in raid functionality is designed for COW workloads, whereas mdraid isn't. On top of that, I would be willing to bet that they were using the dup profile for metadata when testing mdraid (which is the default when using a single disk), which isn't a fair comparison because it stores more data in that case than the BTRFS raid.Hi,Le 04/10/2015 14:03, Lionel Bouton a écrit :[...] This focus on single reader RAID1 performance surprises me. 1/ AFAIK the kernel md RAID1 code behaves the same (last time I checked you need 2 processes to read from 2 devices at once) and I've never seen anyone arguing that the current md code is unstable.To better illustrate my point. According to Phoronix tests, BTRFS RAID-1 is even faster than md RAID1 most of the time. http://www.phoronix.com/scan.php?page=article&item=btrfs_raid_mdadm&num=1 The only case where md RAID1 was noticeably faster is sequential reads with FIO libaio.
If you do the same thing with ZFS, I'd expect that you would see similar results (although probably with a bigger difference between ZFS and mdraid). A much better comparison (which _will_ sway in mdraid's favor) would be running XFS or ext4 (or even JFS) on top of mdraid, as that is the regular usage of mdraid.
Furthermore, there is no sane reason to be running BTRFS on top of a single mdraid device, thus this was even less of a reasonable comparison. It is worth noting however, that using BTRFS raid1 on top of two md RAID0 devices is significantly faster than BTRFS RAID10.
No reasonable person should be basing their analysis on results from someone else's testing without replicating said results themselves, especially when those results are based on benchmarks and not real workloads. This goes double for Phoronix, as they are essentially paid to make whatever the newest technology on Linux is look good.So if you base your analysis on Phoronix tests when serving large files to a few clients maybe md could perform better. In all other cases BTRFS RAID1 seems to be a better place to start if you want performance. According to the bad performance -> unstable logic, md would then be the less stable RAID1 implementation which doesn't make sense to me.
Like I said above, a large part of this is probably because BTRFS raid was designed for COW workloads, and mdraid wasn't.I'm not even saying that BTRFS performs better than md for most real-world scenarios (these are only benchmarks), but that arguing that BTRFS is not stable because it has performance issues still doesn't make sense to me. Even synthetic benchmarks aren't enough to find the best fit for real-world scenarios, so you could always find a very restrictive situation where any filesystem, RAID implementation, volume manager could look bad even the most robust ones. Of course if BTRFS RAID1 was always slower than md RAID1 the logic might make more sense. But clearly there were design decisions and performance tuning in BTRFS that led to better or similar performance in several scenarios, if the remaining scenarios don't get attention it may be because they represent a niche (at least from the point of view of the developers) not a lack of polishing.
smime.p7s
Description: S/MIME Cryptographic Signature
