[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-07-10 15:26:17
Message-ID: CAJCQCtSmb-U=yabz7UkGRwBkWLhgsON_FJQDv9LnKiCt8U_mKw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Fri, Jul 10, 2020, 8:37 AM Matthew Miller <mattdm@fedoraproject.org>
wrote:

> On Fri, Jul 10, 2020 at 12:59:37AM -0600, Chris Murphy wrote:
> > https://paste.centos.org/view/f4165396
> >
> > Two workloads: install and update. It might seem like an update is
> > both read and write dependent, but the rpms are already compressed and
> > don't get compressed again. The differences, I expect, are mostly
> > write performance. And this suggests it's a wash. I'd say this setup
> > is fairly middle of the pack.
> >
> > The space savings, however, isn't a wash.
>
> And if I'm reading it right, a significant win for either btrfs setup over
> ext4.


Space wise or the update time? I think the install times are moderated by
the installer image being tightly bound by xz decompression. The same
happens to zstd compressed RPM for updates, to a lesser degree, and it
might be better threaded, so we see a bigger difference.

There is also noise contributed by the fact it's done in a VM, and using
sparse files. That could have disproportionately penalized ext4.  But as a
sanity test that there isn't anything particular screwy going on
performance wise, it's probably fine.

For example, the kernel load times. Why is the compressed btrfs one so much
faster? Twice. Weird. All three setups, the kernel is on ext4. All six
should be the same. So there is error.

--
Chris Murphy

[Attachment #5 (text/html)]

<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Fri, Jul 10, 2020, 8:37 AM Matthew Miller &lt;<a \
href="mailto:mattdm@fedoraproject.org" target="_blank" \
rel="noreferrer">mattdm@fedoraproject.org</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Fri, Jul 10, 2020 at 12:59:37AM -0600, Chris Murphy \
wrote:<br> &gt; <a href="https://paste.centos.org/view/f4165396" rel="noreferrer \
noreferrer noreferrer" target="_blank">https://paste.centos.org/view/f4165396</a><br> \
&gt; <br> &gt; Two workloads: install and update. It might seem like an update is<br>
&gt; both read and write dependent, but the rpms are already compressed and<br>
&gt; don&#39;t get compressed again. The differences, I expect, are mostly<br>
&gt; write performance. And this suggests it&#39;s a wash. I&#39;d say this setup<br>
&gt; is fairly middle of the pack.<br>
&gt; <br>
&gt; The space savings, however, isn&#39;t a wash.<br>
<br>
And if I&#39;m reading it right, a significant win for either btrfs setup over<br>
ext4.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Space wise or \
the update time? I think the install times are moderated by the installer image being \
tightly bound by xz decompression. The same happens to zstd compressed RPM for \
updates, to a lesser degree, and it might be better threaded, so we see a bigger \
difference.  </div><div dir="auto"><br></div><div dir="auto">There is also noise \
contributed by the fact it&#39;s done in a VM, and using sparse files. That could \
have disproportionately penalized ext4.   But as a sanity test that there isn&#39;t \
anything particular screwy going on performance wise, it&#39;s probably \
fine.</div><div dir="auto"><br></div><div dir="auto">For example, the kernel load \
times. Why is the compressed btrfs one so much faster? Twice. Weird. All three \
setups, the kernel is on ext4. All six should be the same. So there is error.  \
</div><div dir="auto"><br></div><div dir="auto">--</div><div dir="auto">Chris \
Murphy</div><div dir="auto"></div></div>


[Attachment #6 (text/plain)]

_______________________________________________
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]