Re: FYIO: A rant about btrfs

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

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

On 2015-09-16 12:45, Martin Tippmann wrote:
> Hi,
>
> 2015-09-16 17:20 GMT+02:00 Austin S Hemmelgarn <ahferroin7@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?
ZFS has been around for much longer, it's been mature and feature 
complete for more than a decade, and has had a long time to improve 
performance wise.  It is important to note though, that on low-end 
hardware, BTRFS can (and often does in my experience) perform better 
than ZFS, because ZFS is a serious resource hog (I have yet to see a 
stable ZFS deployment with less than 16G of RAM, even with all the fancy 
features turned off).

As for F2FS, it was designed from the ground up for high performance and 
efficiency.  BTRFS started (from what I understand) as more of an 
experiment, and as such the original code was not particularly optimized.
>
> 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.
That depends on what you mean by resolved.  In every test I've done that 
wasn't a specialized benchmark designed to simulate a particular 
workload, I've gotten roughly equal performance between XFS and BTRFS 
(YMMV of course, especially because my usecase is not very typical of 
most people (primarily building software and running BOINC projects)). 
I use BTRFS mostly because it makes online reprovisioning much easier 
(you can't migrate an XFS filesystem to a new block device online, and 
you also can't shrink one).

It's also worth noting that Dave Chinner usually comes forth with 
numbers extolling the value of XFS when a new filesystem gets proposed. 
  In my experience, for small scale usage, ext* gets better performance 
than almost anything else, including XFS.
>
>  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?
Performance is on the roadmap, but the roadmap is notoriously 
short-sighted when it comes to time-frame for completion of something. 
You have to understand also that the focus in BTRFS has also been more 
on data safety than performance, because that's the intended niche, and 
the area most people look to ZFS for.


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