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 MfG bmg
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). 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). 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.
smime.p7s
Description: S/MIME Cryptographic Signature
