Hi, 2015-09-16 17:20 GMT+02:00 Austin S Hemmelgarn <ahferro...@gmail.com>: [...] > 3. He's testing it for a workload is a known and documented problem for > BTRFS, and claiming that that means that it isn't worth considering as a > general usage filesystem. Most people don't run RDBMS servers on their > systems, and as such, such a workload is not worth considering for most > people. > > His points about the degree of performance jitter are valid however, as are > the complaints of apparent CPU intensive stalls in the BTRFS code, and I > occasionally see both on my own systems.
Are there any conceptual or design properties that make btrfs perform worse in this workload compared to ZFS or F2FS that both do CoW and share some similarity? If not then I still think (from a user perspective) it it still interesting too look where the difference is coming from? There is also a quite old talk with some unfortunate numbers for btrfs from the XFS developer Dave Chinner: https://www.youtube.com/watch?v=FegjLbCnoBw - is this already resolved? 2012 is 3 years ago. >From reading the list I understand that btrfs is still very much work in progress and performance is not a top priority at this stage but I don't see why it shouldn't perform at least equally good as ZFS/F2FS on the same workloads. Is looking at performance problems on the development roadmap? regards Martin -- 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
