[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Btrfs by default, the compression option
From:       Chris Murphy <lists () colorremedies ! com>
Date:       2020-08-01 20:00:31
Message-ID: CAJCQCtQQDO9N5p3zxF8eZ9zudyS3mm525bD4U4Foo5ODSJmOKw () mail ! gmail ! com
[Download RAW message or body]

On Sat, Aug 1, 2020 at 6:43 AM Artem Tim <ego.cordatus@gmail.com> wrote:
> 
> @Chris, thanks, i did some tests and now we have some numbers. tl;rd the results is \
> pretty satisfying me, even if there no speedup in my case, but there is a lot disk \
> space could be saved and reduce writes. Probably not worth file a bug, but a little \
> bit weird that with zstd:1 still a little bit slower on HDD and on SSD speed equal.

Your results look consistently faster with compression, whether HDD or SSD.

> ## Results (HDD)
> 
> ### Compression:    lzo
> Took:               6m53s

> ### Compression:    zstd:1
> Took:               7m5s

> ### Compression:    none
> Took:               7m18s


> 
> ## Results (SSD)
> 
> ### Compression:    lzo
> Took:               2m26s
> 
> ### Compression:    zstd:1
> Took:               2m26s

> ### Compression:    none
> Took:               2m24s


There are quite a lot of complexities when benchmarking compression
with workloads. The compression CPU hit is bigger than decompression,
and also the decompression cpu and performance is fairly invariant to
the level used for compression. This generally means we're more likely
to be concerned about negatively impacting max write performance. Some
compiles, while they involve lots of writes, don't ever reach the max
write rate capability of storage, but are very CPU bound processes. Is
it the small amount of CPU, or context switches, that impacts the
writes? I don't know.

Whereas for ~/.cache - for example Firefox and Chrome, these are tons
of small file writes happening all the time and the less to flush the
better, and also the less to read later on the better. This might be a
good candidate for compression, as well as /var /etc /usr. None of
those experience heavy writes that are also time sensitive, about the
heaviest is a system upgrade and since those take long enough most
folks walk away from them anyway, it might not be a big deal if took
slightly longer, although so far I haven't seen that happen.

I think the most common case where compression can slow things down is
heavy writes to very fast media like NVMe. The NVMe writes are simply
faster. And yet, I run compress=zstd:1 on NVMe all day long for all
workloads and at least anecdotally it seems no different than without
compression or using plain ext4 - and for sure it's all more
responsive than when I reboot this same hardware and use Windows 10.

I'll summarize 2 of the 4 ways to do compression by default on Fedora,
that I've thought of so far.
https://bugzilla.redhat.com/show_bug.cgi?id=1851276

a. Anaconda %pre-install script to (1) create /etc /var /usr (2) set a
compression zstd XATTR on them. Everything inherits this as the
installation happens.

b. Anaconda  kickstart `--fsoptions compress=zstd:1` will cause that
mount option to be used for the installation and add it to fstab. Use
%post install script to set a NOCOMPRESS flag on /home.

These are not identical, but approximately equivalent. Perhaps the
most significant difference is the visibility of the compression
option in fstab. This might be a good thing or bad thing, depending on
whether the user thinks this compression is happening system wide or
not. The other difference is that with the (b) option, any new
subvolumes created inside /home do *not* inherit NOCOMPRESS. Should
it? Well that's a different conversation, I've gone back and forth on
it myself and can argue it both ways, but generally I think maybe it
shouldn't inherit because ostensibly a subvolume is a
dedicated/independent files tree and should instead inherit file
system defaults (and mount options modifying them) rather than XATTR
inheritance rules.

All of this is already implemented in the installer, so no churn there.


-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



[prev in list] [next in list] [prev in thread] [next in thread]