Hi,
> On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn <ahferro...@gmail.com> > wrote: > > On 2015-09-16 10:43, M G Berberich wrote: >> Hello, >> >> just for information. I stumbled about a rant about btrfs-performance: >> >> http://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp I read it too. > It is worth noting a few things that were done incorrectly in this testing: > 1. _NEVER_ turn off write barriers (nobarrier mount option), doing so subtly > breaks the data integrity guarantees of _ALL_ filesystems, but especially so > on COW filesystems like BTRFS. With this off, you will have a much higher > chance that a power loss will cause data loss. It shouldn't be turned off > unless you are also turning off write-caching in the hardware or know for > certain that no write-reordering is done by the hardware (and almost all > modern hardware does write-reordering for performance reasons). But can the “nobarrier” mount option affect performances negatively for Btrfs (and not only data integrity)? > 2. He provides no comparison of any other filesystem with TRIM support turned > on (it is very likely that all filesystems will demonstrate such performance > drops. Based on that graph, it looks like the device doesn't support > asynchronous trim commands). I think he means by the text surrounding the only graph that mentions TRIM that this exact same test on the other filesystems he benchmarked yield much better results. > 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. Apparently RDBMS being a problem on Btrfs is neither known nor documented enough (he’s right about the contrast with claiming publicly that Btrfs is indeed production ready). My view on this is that having one filesystem to rule them all (all storage technologies, all use cases) is unrealistic. Also the time when you could put your NAS on an old i386 with 3MB of RAM is over. Compression, checksumming, COW, snapshotting, quotas, etc. are all computationally intensive features. In 2015 block storage has become computationally intensive. How about saying non-root Btrfs RAID10 is the best choice for a Samba NAS on rotational-HDDs with no SMR (my use case)? For root and RDBMS, I use ext4 on a M.2 SSD and with a sane initramfs and the most recent stable kernel. I am happy with the performances and delighted with the features Btrfs provides. I think it is much more productive to document and compare the most successful Btrfs deployments rather than trying to find bugs and bottlenecks for use cases that are the development focus of other filesystems. I don’t know, I might not make a lot of sense here but on top of refactoring the Gotchas, I would be happy to start a successful deployment story section on the wiki and maybe improve my usage of Btrfs along the way (who else here is using Btrfs in a similar fashion?). > 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. Me too. My two cents is that focusing on improving performances for Btrfs-optimal use cases is much more interesting than bringing new features like automatically turning COW off for RDBMS usage or debugging TRIM support. Vincent
signature.asc
Description: Message signed with OpenPGP using GPGMail
