Re: FYIO: A rant about btrfs

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

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.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]