Re: Btrfs by default, the compression option

2020-08-01 Thread Chris Murphy
On Sat, Aug 1, 2020 at 6:43 AM Artem Tim  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-le...@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


Re: Btrfs by default, the compression option

2020-08-01 Thread Artem Tim
@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.

---

! Note: please use monospace font to save formatting.

CPU:Quad Core AMD Athlon X4 845
Kernel: 5.7.11-200.fc32.x86_64 (non-debug)
btrfs-progs:5.7-4
Scheduler:  mq-deadline
Mount options:
- HDD: rw,relatime,seclabel,space_cache=v2,autodefrag
- SSD: rw,relatime,seclabel,compress=lzo,ssd,space_cache=v2

To produce more precise results do some things before:

  - Disable ZRAM:
sudo systemctl stop zram-swap.service

  - Download all necessary packages before build to exclude time required for 
downloading package from internet. After that you can run mock with '--offline' 
option.

  - Before every benchmark clean-up mock:
mock --isolation=simple clean -r fedora-32-x86_64

## How to reproduce?

1. git clone https://src.fedoraproject.org/rpms/gnome-flashback.git
2. cd gnome-flashback/
3. spectool -g gnome-flashback.spec
4. mock --isolation=simple -r fedora-32-(uname -m) --rebuild --sources . --spec 
gnome-flashback.spec --offline

## Results (HDD)

### Compression:lzo
Took:   6m53s

Processed 42492 files, 24340 regular extents (26282 refs), 24114 inline.
Type   Perc Disk Usage   Uncompressed Referenced  
TOTAL   63%  992M 1.5G 1.7G   
none   100%  389M 389M 442M   
lzo 50%  603M 1.1G 1.3G

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

Processed 42492 files, 24232 regular extents (26219 refs), 24861 inline.
Type   Perc Disk Usage   Uncompressed Referenced  
TOTAL   46%  738M 1.5G 1.7G   
none   100%  280M 280M 317M   
zstd35%  458M 1.2G 1.4G

### Compression:zstd:3
Took:   7m8s

Processed 42492 files, 24104 regular extents (26059 refs), 24940 inline.
Type   Perc Disk Usage   Uncompressed Referenced  
TOTAL   45%  707M 1.5G 1.7G   
none   100%  270M 270M 306M   
zstd33%  437M 1.2G 1.4G 

### Compression:none
Took:   7m18s

## Various combinations with aditional tweaks:

### Compression:zstd:1
Addtional mount options:noautodefrag
Took:   7m3s

### Compression:zstd:1
Addtional mount options:noatime
Took:   7m1s

---

## Results (SSD)

### Compression:lzo
Took:   2m26s

### Compression:zstd:1
Took:   2m26s

### Compression:zstd:3
Took:   2m28s

### Compression:zstd:14
Took:   4m9s

Processed 42495 files, 25883 regular extents (27868 refs), 25013 inline.
Type   Perc Disk Usage   Uncompressed Referenced  
TOTAL   42%  673M 1.5G 1.7G   
none   100%  272M 272M 310M   
zstd30%  401M 1.2G 1.4G 

### Compression:none
Took:   2m24s
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-29 Thread Samuel Sieb

On 7/10/20 1:56 AM, Nicolas Mailhot via devel wrote:

Le jeudi 09 juillet 2020 à 23:47 +, Zachary Lym a écrit :

Yes, it's completely reasonable to not do it. It might seem like a
big
change on its own, but Btrfs has had native compression for 10+
years,
and at least three years for most all of the workloads at Facebook.
So
it's quite safe.


But it has been eating data as recently as 2018 [1] and the Debian
wiki warns strongly against using compression that is dated for 2020
[2].  The project will already see a large number of new bugs thanks
to the wider breadth of hardware, why throw in an additional variable
when you can flip it on in six months anyway?


Compression will increase the risk of data loss, because compression
removes data duplication that could be used to reconstruct data in case
of corruption. If you add duplication over compression to make it
recovery-safe, the wins are not so good.


How does that increase the risk?  What data duplication is it removing? 
If your hard drive flips a bit in just about any file, you're not likely 
to fix it.  System files can be replaced easily.  Most user important 
files are already compressed anyway.  .jpg, .ogg (.mp3), .odt, etc.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-29 Thread Chris Murphy
On Wed, Jul 29, 2020 at 2:59 PM Artem Tim  wrote:
>
> I am experimenting now with various compression in Fedora and noticed 
> slowdowns with compression only for mock at this moment. On 4-core CPU 
> building in mock with zstd:1 on HDD is slower. Also 'autodefrag' and 
> 'space_cache=v2' options enabled on HDD.

Also, please include the exact kernel version in the bug report.
Either the literal file name or the rpm - because we need to know if
it's a debug enabled kernel. Fedora debug kernels enable
CONFIG_LOCKDEP which slows down Btrfs dramatically more than other
file systems.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-29 Thread Chris Murphy
On Wed, Jul 29, 2020 at 2:59 PM Artem Tim  wrote:
>
> I am experimenting now with various compression in Fedora and noticed 
> slowdowns with compression only for mock at this moment. On 4-core CPU 
> building in mock with zstd:1 on HDD is slower. Also 'autodefrag' and 
> 'space_cache=v2' options enabled on HDD.

Is there anything else going on at the same time? Could you file a bug
against the kernel and in the Assignee field, replace with
fedora-kernel-bt...@fedoraproject.org and describe the setup with
simple reproduce steps (as in, i never use mock) so the we can do some
A/B testing?

I have a ~9 year old core i7, and zstd:1 single thread throughput is
definitely faster for both reads and writes than the SSD that's in it,
let alone the original HDD that was in it. It should be faster with
zstd:1 if anything. I expect a compile means 100% writes are new file
writes and not many, if any at all, writes within a file. That is what
would trigger autodefrag.

Thanks,

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-29 Thread Artem Tim
I am experimenting now with various compression in Fedora and noticed slowdowns 
with compression only for mock at this moment. On 4-core CPU building in mock 
with zstd:1 on HDD is slower. Also 'autodefrag' and 'space_cache=v2' options 
enabled on HDD.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-10 Thread Chris Murphy

> 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.

New longer lasting paste. Same info.
https://pastebin.com/nvpvAy0k

Mostly this was just a sanity test, I'll get around to some baremetal tests 
eventually.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-10 Thread Mark Otaris
Maybe Workstation could provide Déjà Dup in the default system to make
it discoverable and encourage users to create backups.

It has to be an installed application (can’t be a website), and most
users would benefit from having backups.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-10 Thread Chris Murphy
On Fri, Jul 10, 2020, 8:37 AM Matthew Miller 
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-10 Thread Matthew Miller
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.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-10 Thread Nicolas Mailhot via devel
Le jeudi 09 juillet 2020 à 23:47 +, Zachary Lym a écrit :
> > Yes, it's completely reasonable to not do it. It might seem like a
> > big
> > change on its own, but Btrfs has had native compression for 10+
> > years,
> > and at least three years for most all of the workloads at Facebook.
> > So
> > it's quite safe.
> 
> But it has been eating data as recently as 2018 [1] and the Debian
> wiki warns strongly against using compression that is dated for 2020
> [2].  The project will already see a large number of new bugs thanks
> to the wider breadth of hardware, why throw in an additional variable
> when you can flip it on in six months anyway?

Compression will increase the risk of data loss, because compression
removes data duplication that could be used to reconstruct data in case
of corruption. If you add duplication over compression to make it
recovery-safe, the wins are not so good.

However, that is consistent with btrf’s recovery story, and reliance on
restoring from backups in case of problems.

What is the workstation backup story? I would be a lot more confident
in this change, if the things Facebook relies on to make btrfs
corruption non events, were available workstation side.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-10 Thread Chris Murphy
On Wed, Jul 8, 2020 at 9:50 AM Matthew Miller  wrote:
>
> More data is always better. I like qualifying the situations in that way. I
> think we should make our decision based on the "center" rather than the
> edges, though.
>
> For I hope obvious reasons, I'd love to see this tested on a Lenovo X1
> Carbon Gen 8 with the default SSD options.
>
> And, for benchmarks, I'm thinking more application benchmarks than a
> benchmark of the compression itself. How much does compressed /usr affect
> boot times for GNOME and KDE? What about startup time for LibreOffice,
> Firefox, etc? Any impact on run-time usage?

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.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-09 Thread drago01
On Friday, July 10, 2020, Zachary Lym  wrote:

> > Yes, it's completely reasonable to not do it. It might seem like a big
> > change on its own, but Btrfs has had native compression for 10+ years,
> > and at least three years for most all of the workloads at Facebook. So
> > it's quite safe.
>
> But it has been eating data as recently as 2018 [1] and the Debian wiki
> warns strongly against using compression that is dated for 2020 [2].  The
> project will already see a large number of new bugs thanks to the wider
> breadth of hardware, why throw in an additional variable when you can flip
> it on in six months anyway?


Then again only for new installs. Would be better to move all of it by six
months - enabling it without taking advantage of such features would be
kind of wasteful. Also if two years is "recent" how do 6 months change
anything?


>
> 1: https://www.spinics.net/lists/linux-btrfs/msg81293.html
> 2: https://wiki.debian.org/Btrfs#Warnings
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-09 Thread Zachary Lym
> Yes, it's completely reasonable to not do it. It might seem like a big
> change on its own, but Btrfs has had native compression for 10+ years,
> and at least three years for most all of the workloads at Facebook. So
> it's quite safe.

But it has been eating data as recently as 2018 [1] and the Debian wiki warns 
strongly against using compression that is dated for 2020 [2].  The project 
will already see a large number of new bugs thanks to the wider breadth of 
hardware, why throw in an additional variable when you can flip it on in six 
months anyway?

1: https://www.spinics.net/lists/linux-btrfs/msg81293.html
2: https://wiki.debian.org/Btrfs#Warnings
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-09 Thread Matthew Miller
On Wed, Jul 08, 2020 at 02:20:06PM -0700, John M. Harris Jr wrote:
> > Yeah I guess for /usr the most relevant write metric is "does it slow down
> > DNF upgrades or install operations enough to be noticeable / annoying /
> > problematic"?
> More importantly, does it hurt the performance of installed packages?

Definitely. I expect for reads the impact will be negligible in most cases
(possible improvements in some, even), but it's important to validate that.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread John M. Harris Jr
On Wednesday, July 8, 2020 10:20:30 AM MST Matthew Miller wrote:
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> 
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've seen equal or better read performance, there can be a write
> > performance drop if the IO storage has been upgraded. Sample size 1,
> > and the workload was kernel compiling.
> 
> 
> Yeah I guess for /usr the most relevant write metric is "does it slow down
> DNF upgrades or install operations enough to be noticeable / annoying /
> problematic"?

More importantly, does it hurt the performance of installed packages?

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Chris Murphy
On Wed, Jul 8, 2020 at 12:54 PM Adam Williamson
 wrote:
>
> On Wed, 2020-07-08 at 00:24 -0600, Chris Murphy wrote:
> > Hi,
> >
> > The change proposal has a 'compression option' and we kinda need to
> > get organized.
> > https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression
>
> It feels to me like this might be a great area to slow down a bit and
> not try to do everything at once.
>
> Why don't we just make the simplest change for F33 - going to btrfs by
> default - and see how that goes, and consider the 'options' for F34 or
> later, rather than changing too much stuff at once?

Yes, it's completely reasonable to not do it. It might seem like a big
change on its own, but Btrfs has had native compression for 10+ years,
and at least three years for most all of the workloads at Facebook. So
it's quite safe. It does, however, touch parts in Anaconda.

So yeah, we definitely do not have to do it. But if we are, I guess my
point is, we need to get serious and act quick like a bunny. This
isn't gonna be some late addition.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Chris Murphy
On Wed, Jul 8, 2020 at 1:45 PM Matthew Miller  wrote:
>
> On Wed, Jul 08, 2020 at 11:37:11AM -0600, Chris Murphy wrote:
> > If it's the center, I think that favors the mount option approach and
> > do it with the lowest level of compression, i.e. zstd:1. But this
> > suggests more benchmarking still, to make certain it's well understood
> > what the range of write performance hit could be in those scenarios.
> > Whereas the curated approach can just bypass most of that question -
> > the payload and workload for flatpak and usr and containers is fairly
> > fixed across all Fedora users rather than mixed content and workloads
> > found in ~/
>
> I just did some quick tests out of curiousity. I tarred up /usr on my
> system, resulting in a 9.8GB file. Ran this in my home dir on a
> run-of-the-mill Western Digital SSD.

Btrfs uses a cheap entropy estimator to decide if it should even try
to compress blocks. So it won't always do it. Hence results like this:

$ sudo compsize /usr
Processed 204133 files, 108496 regular extents (114715 refs), 101700 inline.
Type   Perc Disk Usage   Uncompressed Referenced
TOTAL   57%  3.2G 5.7G 6.2G
none   100%  1.8G 1.8G 1.9G
zstd36%  1.3G 3.8G 4.3G


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Matthew Miller
On Wed, Jul 08, 2020 at 11:37:11AM -0600, Chris Murphy wrote:
> If it's the center, I think that favors the mount option approach and
> do it with the lowest level of compression, i.e. zstd:1. But this
> suggests more benchmarking still, to make certain it's well understood
> what the range of write performance hit could be in those scenarios.
> Whereas the curated approach can just bypass most of that question -
> the payload and workload for flatpak and usr and containers is fairly
> fixed across all Fedora users rather than mixed content and workloads
> found in ~/

I just did some quick tests out of curiousity. I tarred up /usr on my
system, resulting in a 9.8GB file. Ran this in my home dir on a
run-of-the-mill Western Digital SSD.


This results in:

compression file  compression   % better than 
  level size ratio previous

1   4.1G41.36%- 
2   3.8G38.97%   6.1%
3   3.6G36.81%   5.9%
4   3.6G36.36%   1.2%
5   3.5G35.63%   2.8%
6   3.5G35.33%   2.0%

9   3.4G34.19%-
   19   2.8G29.72%-


That's pretty good even at level 1. I don't think my setup is useful for
timing benchmarks, and also that takes more care than I want to put into it
this minute, but the interesting note is that levels 1-4 are all about the
same in speed (within 10 seconds) and level 5 suddenly 3x slower. I assume
that's not surprising to anyone who knows how zstd works. But also, unless
you go to crazy high levels, the gains above level 3 really drop off.

(19, by the way, is amazingly slow. Took almost an hour.)




-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Martin Jackson



It feels to me like this might be a great area to slow down a bit and
not try to do everything at once.

Why don't we just make the simplest change for F33 - going to btrfs by
default - and see how that goes, and consider the 'options' for F34 or
later, rather than changing too much stuff at once


Considering how controversial the change has been already,?? I think it 
would make a lot of sense to make one change at a time. If someone were 
to have a bad experience with the new default, it would be unclear 
whether that's because of the filesystem itself or because of the 
options we chose to deploy the filesystem with. If we make those changes 
separately, and the compression change goes badly, the changes would 
still be clearly independent.


Changing one thing at a time is responsible change management in any 
case, especially when we're talking about defaults.


Thanks,

Marty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Adam Williamson
On Wed, 2020-07-08 at 00:24 -0600, Chris Murphy wrote:
> Hi,
> 
> The change proposal has a 'compression option' and we kinda need to
> get organized.
> https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression

It feels to me like this might be a great area to slow down a bit and
not try to do everything at once.

Why don't we just make the simplest change for F33 - going to btrfs by
default - and see how that goes, and consider the 'options' for F34 or
later, rather than changing too much stuff at once?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Chris Murphy
On Wed, Jul 8, 2020 at 11:20 AM Matthew Miller  wrote:
>
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've seen equal or better read performance, there can be a write
> > performance drop if the IO storage has been upgraded. Sample size 1,
> > and the workload was kernel compiling.
>
> Yeah I guess for /usr the most relevant write metric is "does it slow down
> DNF upgrades or install operations enough to be noticeable / annoying /
> problematic"?

I'm pretty fussy and impatient. I think I'd notice. But this is not a
reliable metric. I think a sane test might be looking at the
program.log for a netinstall on lvm+ext4 vs btrfs vs btrfs +compress.
Delete the download portion of the test to eliminate network variation
error, and only look at payload delivery time.

I have done this just today with a Live installation, but this has the
problem that we're significantly read bound due to a tightly wound up
xz compressed image. That acts as a moderator for whoever is really
faster. All these results tell is is that we don't have a problem with
live install performance being meaningfully different.

https://paste.centos.org/view/7ce7b52f


> > SD Card and eMMC  it's a win for sure. Also an argument could be made
> > do use Btrfs+compression on USB sticks. This class of flash will just
> > return garbage if they encounter uncorrectable errors - rather than a
> > discrete read error. In this case, Btrfs refuses to hand over the
> > corrupt data, in normal operation. A good question is, whether the
> > desktop should warn that the file is corrupt, and then permit a
> > degraded read somehow to still get the file off the media. It might
> > imply necessary desktop integration.
>
> A related question: Are we planning on using btrfs on live media?

No. It will still be ext4 nested in a squashfs image, and rsync to
copy. There is/was an idea to move to plain squashfs image, and
unsquashfs to copy - but I'm not certain of its status.
https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L6ZQCOYXZOIIOZM7SUFQDGEUEQU2QY7N/

There is a trade off using Btrfs as the image for media.
(a) compression won't be as good as plain squashfs, images will get
bigger. Maybe as much as 20% - but I've done no optimizing to see if
that can be improved.
(b) Always on checksumming of the payload we care about (excludes the
bootloader, kernel, initramfs for the live environment boot). We can
get rid of the long slow one time media checker option. With no
meaningful performance hit to the user. And catch even transient
corruption due to flakey USB media, etc.
(c) We can use rsync for installs to non-btrfs file systems, they
still get the benefit of (b); and an optimization for installs to
Btrfs is using a seed/sprout replication feature that avoids the
decompression/recompression hit of the (b) option because it just
copies compressed block groups intact, it's not a file copy. Also
these things can be chained (dependently stacked in order; not like
independent overlays).
https://btrfs.wiki.kernel.org/index.php/Seed-device

But yea, as Neal says. Not this cycle.

--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Neal Gompa
On Wed, Jul 8, 2020 at 1:20 PM Matthew Miller  wrote:
>
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've seen equal or better read performance, there can be a write
> > performance drop if the IO storage has been upgraded. Sample size 1,
> > and the workload was kernel compiling.
>
> Yeah I guess for /usr the most relevant write metric is "does it slow down
> DNF upgrades or install operations enough to be noticeable / annoying /
> problematic"?
>
> > SD Card and eMMC  it's a win for sure. Also an argument could be made
> > do use Btrfs+compression on USB sticks. This class of flash will just
> > return garbage if they encounter uncorrectable errors - rather than a
> > discrete read error. In this case, Btrfs refuses to hand over the
> > corrupt data, in normal operation. A good question is, whether the
> > desktop should warn that the file is corrupt, and then permit a
> > degraded read somehow to still get the file off the media. It might
> > imply necessary desktop integration.
>
> A related question: Are we planning on using btrfs on live media?
>

Not for this change, no. Part of the reason is that I didn't want to
bite off more than I can chew, and part of it is that I want to
explore some of the Btrfs-specific enhancements with seed images and
the seed/sprout flow before I go down that road.

There's some seriously cool opportunities there, but I want to
actually try it before I propose it. :)

We are, however, changing all the disk image deliverables to Btrfs
(like the ARM ones), since that's how people wind up using it anyway.



-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: [External] Re: Btrfs by default, the compression option

2020-07-08 Thread Chris Murphy
On Wed, Jul 8, 2020 at 10:54 AM Mark Pearson  wrote:
>
> I personally haven't had any experience with btrfs but if there are any 
> guidelines on testing that we can do and what data should be collected to 
> help out let me know and I'll see if we can hit up some of our platforms and 
> get some numbers.
>

As much as benchmarks make me loopy... they are only as valid, as they
actually represent the workload, and many don't. But. The Phoronix
test suite might be a starting point in finding unusually bad things
to look into. (Conversely, unusually good results I consider equally
suspicious but, like, haha ... am I gonna care as much? No.)


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Chris Murphy
On Wed, Jul 8, 2020 at 9:50 AM Matthew Miller  wrote:
>
> On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> > 2. Benchmarking: this is hard. A simple tool for doing comparisons
> > among algorithms on a specific bit of hardware is lzbench.
> > https://github.com/inikep/lzbench
> > How to compile on F32.
> > https://github.com/inikep/lzbench/issues/69
> > But is that adequate? How do we confirm/deny on a wide variety of
> > hardware that this meets the goal? And how is this test going to
> > account for parallelization, and read ahead? Do we need a lot of data
> > or is it adequate to get a sample "around the edges" (e.g. slow cpu
> > fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow
> > drive). What algorithm?
>
> More data is always better. I like qualifying the situations in that way. I
> think we should make our decision based on the "center" rather than the
> edges, though.

If it's the center, I think that favors the mount option approach and
do it with the lowest level of compression, i.e. zstd:1. But this
suggests more benchmarking still, to make certain it's well understood
what the range of write performance hit could be in those scenarios.
Whereas the curated approach can just bypass most of that question -
the payload and workload for flatpak and usr and containers is fairly
fixed across all Fedora users rather than mixed content and workloads
found in ~/


> For I hope obvious reasons, I'd love to see this tested on a Lenovo X1
> Carbon Gen 8 with the default SSD options.
>
> And, for benchmarks, I'm thinking more application benchmarks than a
> benchmark of the compression itself. How much does compressed /usr affect
> boot times for GNOME and KDE? What about startup time for LibreOffice,
> Firefox, etc? Any impact on run-time usage?
>
>
> [...]
> > D. Which directories? Some may be outside of the installer's scope.
>
> As I noted in the bugzilla entry, the /var/log on this system compresses to
> 3.6% of its original size.

Yep. I'm not opposed to it by any means. I'm not sure what things
other than VMs and databases would be there - and we still have to
figure out who "owns" those locations to decide how we get them to set
nodatacow.

There is bit of a rabbit hole for /var/log/journals. systemd-journald
detects btrfs and automatically does nodatacow on its journals. That
means no compression. On a HDD, it makes sense. But on SSD the files
are relatively small and while fragmentation can be bad the tracking
isn't that bad on an SSD, I'm pretty sure compression makes up for it
but I haven't benchmarked it. Anyway I 'touch
/etc/tmpfiles.d/journal-nocow.conf' to prevent the setting of
nodatacow on journals.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Matthew Miller
On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> I expect beefy CPU systems, including gaming systems, to have the same
> or better read/write performance using mount option compress=zstd:1.
> Where I've seen equal or better read performance, there can be a write
> performance drop if the IO storage has been upgraded. Sample size 1,
> and the workload was kernel compiling.

Yeah I guess for /usr the most relevant write metric is "does it slow down
DNF upgrades or install operations enough to be noticeable / annoying /
problematic"?

> SD Card and eMMC  it's a win for sure. Also an argument could be made
> do use Btrfs+compression on USB sticks. This class of flash will just
> return garbage if they encounter uncorrectable errors - rather than a
> discrete read error. In this case, Btrfs refuses to hand over the
> corrupt data, in normal operation. A good question is, whether the
> desktop should warn that the file is corrupt, and then permit a
> degraded read somehow to still get the file off the media. It might
> imply necessary desktop integration.

A related question: Are we planning on using btrfs on live media?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Chris Murphy
On Wed, Jul 8, 2020 at 5:13 AM Kamil Paral  wrote:
>
> On Wed, Jul 8, 2020 at 11:22 AM Dominique Martinet  
> wrote:
>>
>> Please test, but if a file is deemed not compressible (based on, not
>> sure what? the first few blocks?) then it will be stored in the
>> non-compressed version.
>> You can check with compsize after the fact if the file had been
>> compressed or not.
>>
>> This should be true unless the compress-force mount option is used, even
>> the chattr is only a hint
>
>
> OK, this is an interesting piece of information I wasn't aware of. In this 
> case, if the btrfs heuristics work OK in the majority of cases, the 
> performance hit might not be there, as I feared. Some thorough investigation 
> would be needed, though.

There is a cheap estimator of how well blocks will compress and Btrfs
will do an early bail, and not compress if there's no good gain. It's
common to see mixed compression on files.

I expect beefy CPU systems, including gaming systems, to have the same
or better read/write performance using mount option compress=zstd:1.
Where I've seen equal or better read performance, there can be a write
performance drop if the IO storage has been upgraded. Sample size 1,
and the workload was kernel compiling.

The mount option method is file system wide, and permits level to be
specified (except lzo). Whereas using the XATTR is
subvolume/directory/file granularity, and works by inheritance when
set on a directory, it doesn't yet support levels. Upstream
development tells me it's straightforward to include the level in the
XATTR - but that is an RFE so we can't plan for it just yet. The
default level for zstd is 3. The read time performance is about the
same, but the write time performance takes a bigger hit. This isn't a
big deal if we're "curating" specific directories that are likely to
have their write performance limited by, for example internet
bandwidth, or perception wise that the offline update takes however
many tens of seconds longer.

I also tentatively agree that many users' drives are not likely to see
their drive lifetime writes exceeded without compression. But if they
can save ~50% of the space without a read time performance hit (or
even a gain) that's a win. For folks compiling, that needs more
testing. It might work out in favor of some cases and not others - and
if they do a lot of writes the write amplification reduction is more
meaningful. And also some low end very high density chip SSDs can have
low write endurance these days.

SD Card and eMMC  it's a win for sure. Also an argument could be made
do use Btrfs+compression on USB sticks. This class of flash will just
return garbage if they encounter uncorrectable errors - rather than a
discrete read error. In this case, Btrfs refuses to hand over the
corrupt data, in normal operation. A good question is, whether the
desktop should warn that the file is corrupt, and then permit a
degraded read somehow to still get the file off the media. It might
imply necessary desktop integration.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


RE: [External] Re: Btrfs by default, the compression option

2020-07-08 Thread Mark Pearson
> -Original Message-
> From: Matthew Miller 
> Sent: Wednesday, July 8, 2020 11:51 AM
> 
> On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> > 2. Benchmarking: this is hard. A simple tool for doing comparisons
> > among algorithms on a specific bit of hardware is lzbench.
> > https://github.com/inikep/lzbench
> > How to compile on F32.
> > https://github.com/inikep/lzbench/issues/69
> > But is that adequate? How do we confirm/deny on a wide variety of
> > hardware that this meets the goal? And how is this test going to
> > account for parallelization, and read ahead? Do we need a lot of data
> > or is it adequate to get a sample "around the edges" (e.g. slow cpu
> > fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow
> > drive). What algorithm?
> 
> More data is always better. I like qualifying the situations in that way. I
> think we should make our decision based on the "center" rather than the
> edges, though.
> 
> For I hope obvious reasons, I'd love to see this tested on a Lenovo X1
> Carbon Gen 8 with the default SSD options.
> 
I personally haven't had any experience with btrfs but if there are any 
guidelines on testing that we can do and what data should be collected to help 
out let me know and I'll see if we can hit up some of our platforms and get 
some numbers.

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Matthew Miller
On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> 2. Benchmarking: this is hard. A simple tool for doing comparisons
> among algorithms on a specific bit of hardware is lzbench.
> https://github.com/inikep/lzbench
> How to compile on F32.
> https://github.com/inikep/lzbench/issues/69
> But is that adequate? How do we confirm/deny on a wide variety of
> hardware that this meets the goal? And how is this test going to
> account for parallelization, and read ahead? Do we need a lot of data
> or is it adequate to get a sample "around the edges" (e.g. slow cpu
> fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow
> drive). What algorithm?

More data is always better. I like qualifying the situations in that way. I
think we should make our decision based on the "center" rather than the
edges, though.

For I hope obvious reasons, I'd love to see this tested on a Lenovo X1
Carbon Gen 8 with the default SSD options.

And, for benchmarks, I'm thinking more application benchmarks than a
benchmark of the compression itself. How much does compressed /usr affect
boot times for GNOME and KDE? What about startup time for LibreOffice,
Firefox, etc? Any impact on run-time usage?


[...]
> D. Which directories? Some may be outside of the installer's scope.

As I noted in the bugzilla entry, the /var/log on this system compresses to
3.6% of its original size.

(Methodology: I tarred up the dir and then ran zstd -1 on the tar file. If I
use -19, it's unsurprisingly slow and saves another whole one percent of the
original.)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread John M. Harris Jr
On Wednesday, July 8, 2020 1:10:12 AM MST Kamil Paral wrote:
> On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy  wrote:
> > D. Which directories? Some may be outside of the installer's scope.
> > 
> > /usr
> > /var/lib/flatpak
> > ~/.local/share/flatpak
> 
> I have a concern regarding games. Currently, we have a few a bit more
> demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In
> the glorious future (tm) we might get more. Games are very sensitive to
> available CPU cycles and context switching and usually come with their data
> files already compressed. Including the btrfs compression by default on
> flatpak dirs could lead to lowered performance whenever the game tries to
> load some assets (older titles do that during the loading screen, newer
> titles stream new assets constantly during gameplay and any slowdown
> manifests as game stuttering).

Flatpack stuff aside, we have games like 0AD, Xonotic, Albion and others in 
the repos as well, where compression should not be used.

Also, just wondering, how are you planning to enable compression on an unknown 
user's home directory? As a modification to the homedir helper?

-- 
John M. Harris, Jr.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Kamil Paral
On Wed, Jul 8, 2020 at 11:22 AM Dominique Martinet 
wrote:

> Please test, but if a file is deemed not compressible (based on, not
> sure what? the first few blocks?) then it will be stored in the
> non-compressed version.
> You can check with compsize after the fact if the file had been
> compressed or not.
>
> This should be true unless the compress-force mount option is used, even
> the chattr is only a hint
>

OK, this is an interesting piece of information I wasn't aware of. In this
case, if the btrfs heuristics work OK in the majority of cases, the
performance hit might not be there, as I feared. Some thorough
investigation would be needed, though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Dominique Martinet
Kamil Paral wrote on Wed, Jul 08, 2020:
> On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy  wrote:
> 
> > D. Which directories? Some may be outside of the installer's scope.
> >
> > /usr
> > /var/lib/flatpak
> > ~/.local/share/flatpak
> 
> I have a concern regarding games. Currently, we have a few a bit more
> demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In
> the glorious future (tm) we might get more. Games are very sensitive to
> available CPU cycles and context switching and usually come with their data
> files already compressed. Including the btrfs compression by default on
> flatpak dirs could lead to lowered performance whenever the game tries to
> load some assets (older titles do that during the loading screen, newer
> titles stream new assets constantly during gameplay and any slowdown
> manifests as game stuttering).

Please test, but if a file is deemed not compressible (based on, not
sure what? the first few blocks?) then it will be stored in the
non-compressed version.
You can check with compsize after the fact if the file had been
compressed or not.

This should be true unless the compress-force mount option is used, even
the chattr is only a hint


> I'm personally more concerned about reduced performance in e.g. my web
> browser than disk wear out. I don't see much harm in compressing /usr,
> because it's a read-only location that gets loaded once when the app starts
> (it might delay the app startup a bit, though, and decrease the perceived
> snappiness of the desktop). But I'm concerned about compressing locations
> which are hit often, like ~/.var or ~/.cache. I've had my 120GB SSD for 5
> years and I'm just at 10% of expected TBW (total bytes written). If the SSD
> lasts 50 or 100 years is not really important for me, but the desktop and
> app responsiveness is (and game performance, of course:)). I think write
> amplification is a problem specific to devices with SD cards, and for
> anyone else, it might be better to leave it unset and let people enable it
> (it's simple) if they want it for their use case.

This obviously needs testing on a wide variety of hardware but I haven't
noticed any difference in the feeling on an intel laptop (kabylake i5
throttled at 2GHz) ; that being said firefox isn't the most responsive
app in my book...

-- 
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


Re: Btrfs by default, the compression option

2020-07-08 Thread Kamil Paral
On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy  wrote:

> D. Which directories? Some may be outside of the installer's scope.
>
> /usr
> /var/lib/flatpak
> ~/.local/share/flatpak
>

I have a concern regarding games. Currently, we have a few a bit more
demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In
the glorious future (tm) we might get more. Games are very sensitive to
available CPU cycles and context switching and usually come with their data
files already compressed. Including the btrfs compression by default on
flatpak dirs could lead to lowered performance whenever the game tries to
load some assets (older titles do that during the loading screen, newer
titles stream new assets constantly during gameplay and any slowdown
manifests as game stuttering).

May it make sense to have different compression defaults per Edition/Spin?
For example, Workstation is likely used on computers which have sufficient
disk space, don't suffer from disk wear out that much (compared to SD
cards), and users are likely to play games on them. On the other hand, ARM
or IoT devices are the very opposite and compression can be very useful
there.


> /var/lib/containers/
> ~/.local/share/containers/
> ~/.var
>

If we enable it on ~/.var, it will affect all Steam games installed through
the Steam flatpak. So any AAA games you play including those emulated
through Proton will need to deal with extra compression. I find it unlikely
that the user experience would be unchanged. It would be similar to
Microsoft enabling disk compression on Program Files by default. I actually
tried to figure out which locations are compressed by default on Windows
10, and I failed in searching, but I looked at my Win10 instance and I
didn't find any folders that would have compression enabled.


> ~/.cache
>
> (Plausible this list should be reversed. While compressing ~/.cache
> may not save much space, it's likely hammered with more changes than
> other locations, hence more benefit in terms of reducing write
> amplification.)
>

I'm personally more concerned about reduced performance in e.g. my web
browser than disk wear out. I don't see much harm in compressing /usr,
because it's a read-only location that gets loaded once when the app starts
(it might delay the app startup a bit, though, and decrease the perceived
snappiness of the desktop). But I'm concerned about compressing locations
which are hit often, like ~/.var or ~/.cache. I've had my 120GB SSD for 5
years and I'm just at 10% of expected TBW (total bytes written). If the SSD
lasts 50 or 100 years is not really important for me, but the desktop and
app responsiveness is (and game performance, of course:)). I think write
amplification is a problem specific to devices with SD cards, and for
anyone else, it might be better to leave it unset and let people enable it
(it's simple) if they want it for their use case.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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