On Sat, 2020-06-27 at 13:34 -0600, Chris Murphy wrote:
> On Sat, Jun 27, 2020 at 11:59 AM Konstantin Kharlamov
> <hi-an...@yandex.ru> wrote:
> > On Sat, 2020-06-27 at 17:00 +0300, Konstantin Kharlamov wrote:
> > > Another reason worth mentioning: BTRFS per se is slow. If you look at
> > > benchmarks
> > > on Phoronix comparing BTRFS with others, BTRFS is rarely even on par with
> > > them.
> > 
> > Btw, I should also add here: it may be clear that in ideal situtation BTRFS
> > will
> > always be slower than non-COW file systems. The problem however, it is not
> > even
> > on par with the other open-source COW file system, which is ZFS.
> > 
> > Some months ago at my dayjob I was performing benchmarks, and out of
> > curiosity I
> > also compared latest released (as of then, it was 5.6 kernel) BTRFS with
> > latest
> > master of ZFS (which was of a commit b29e31d80 and a kernel 5.4).
> > 
> > The setup was a RAID5 on 10 SSDs, and a benchmark was three 20-minutes long
> > runs
> > of vdbench with random 70% reads and random 30% writes. For BTRFS I also
> > used
> > `space_cache=v2` mount option. Results were:
> > 
> > FS    | run 1, IOPS | run 2, IOPS | run 3, IOPS
> > BTRFS | 65723.9     | 56474.5     | 55090.2
> > ZFS   | 96846.1     | 79797.9     | 76249.4
> For the sake of the argument I will accept the above as facts.
> But raid5 correlates to the desktop how? Does my desktop workload need
> 96K IOPS? Do I notice the difference even if it can be measured? And
> the vdbench command used is? And this particular vdbench command
> produces a benchmark that mimics what workload found on the desktop?
> There is no hand waving away the relevance of these questions if
> you're going to propose performance benchmarks are relevant.

Fair enough.

> > So, summing up this and my previous mail overall, I do not think that for
> > ordinary desktop BTRFS is currently any good, compared to EXT4 or XFS.
> Not persuasive.
> I think your argument is improved if you say we need more and better
> benchmarking that mimics the actual workloads we care about; or times
> a set of test cases that people can try themselves and reproduce.
> I use a variety of OS's on a variety of hardware, including the laptop
> I'm using now which is Fedora and Windows dual boot and I'm not
> suspicious of performance issues of any kind: Fedora's faster, period.
> Might it seem even faster if it were ext4? I've done it, and I don't
> think so. So how do you produce a benchmark that accounts for the
> user's perception of performance, rather than just raw performance?
> Because maybe btrfs is faster. Maybe it's slower. But does it matter?
> If it took 5 seconds for GNOME Terminal to launch I'd be mad. 21
> seconds is just nonsense. So yes it does matter, but what's the
> threshold at which it matters? These benchmarks aren't capturing
> either the reality or the feeling. So we need better (more relevant)
> benchmarks to have a proper discussion.
> For the vast majority of things I'm doing, even if it were the case
> that some things are slower, *I* am still much slower than whatever
> extra latency there may be. And same goes for the reverse, if btrfs
> compression makes some things slightly faster, will I notice? I don't
> know. But is that the only metric? I know for sure my hardware is
> doing far fewer writes (and reads for that matter), so there is less
> wear and tear on the hardware. Is that saving me 50 cents or $50 over
> the life of the hardware? I don't know but I do know it's better than
> no compression, overall.

Thank you, I see your point. Since it seems to also be present in the reply to
my other mail, let's continue there.
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to