Re: FYIO: A rant about btrfs

[Zia Nayamuth <zedestructor@gmail.com>]

Some response to your criticism:

1. How would that hole fare with a fully battery-backed/flash-backed 
path (battery-backed or flash-backed HBA with disks with full power-loss 
protection, like the Intel S3500)? In such a situation (quite 
commonplace in server-land), power-loss should not cause any data loss 
since all data in the cache is guaranteed to be committed to 
non-volatile memory at some point (whether such assurances may be 
trusted is another matter entirely though, and well outside the scope of 
this discussion).

2. Fair point. I'd like to know his hardware, given how strongly 
hardware can influence things.

3. It's pretty obvious that the author of that blog is specifically 
targeting OLTP performance (explicit statement in intro, choice of 
benchmark, name and focus of blog), not common-case, and even states 
that in the first two paragraphs of his conclusion. The focus is 
somewhat less clear in said conclusion, namely, is he truly talking 
about general purpose use or is he talking about general purpose OLTP use?

-- 
Zia Nayamuth

On 17/09/2015 01:20, Austin S Hemmelgarn 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
>>
>>     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.
>