Russell Coker posted on Sat, 03 Oct 2015 18:32:17 +1000 as excerpted: > Last time I checked a BTRFS RAID-1 filesystem would assign each process > to read from one disk based on it's PID. Every RAID-1 implementation > that has any sort of performance optimisation will allow a single > process that's reading to use both disks to some extent. > > When the BTRFS developers spend some serious effort optimising for > performance it will be useful to compare BTRFS and ZFS.
This is the example I use as to why btrfs isn't really stable, as well. Devs tend to be very aware of the dangers of premature optimization, because done too early, it either means throwing that work away when a rewrite comes, or it severely limits options as to what can be rewritten, if necessary, in ordered to avoid throwing all that work that went into optimization away. So at least for devs that have been around awhile, that don't have some boss that's paying the bills saying optimize now, an actually really good mark of when the /devs/ consider something stable, is when they start focusing on that optimization. Since this rather obvious low hanging fruit bit of optimization hasn't yet been done, then, there's really no question, btrfs doesn't pass the optimized stability test yet, and thus is self-evidently not stable, in the opinion of the very devs working on it. Were they to really consider it stable, this optimization would already be done. So once we see this optimization done, /then/ we can debate whether btrfs is stable yet, or not. Until then, settled question, it's obviously not. It may indeed be some distance into the process of stabilization, "stabiliz_ing_", and I'd characterize it as exactly that, but not yet, "stable". -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
