The change proposal has a 'compression option' and we kinda need to
get organized.

 - Compression saves space, significantly reduces write amplification
and therefore increases flash lifespan, and in some cases increases
 - Desired but not a requirement of the change proposal.

1. Goal: probably the goal performance wise is to perform as good or
better than now. Is it OK if there's a write time performance hit for
a small percent of folks, for a high value target like usr that isn't
updated that often, and is also updated out of band (offline updates
typically, but also isn't something directly related to the daily
workload)? How to decide this?

2. Benchmarking: this is hard. A simple tool for doing comparisons
among algorithms on a specific bit of hardware is lzbench.
How to compile on F32.
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?

3. Improvements and upgrades. We'll do plan A, but learn new things
later, and come up with plan B. How do we get the plan A folks
upgraded to plan B? Or just don't worry?

4. The whole file system (using a mount option) or curated (using an
XATTR set on specific "high value" directories)? This part is
elaborated below.

A.  do this with a mount option '-o compress=zstd:1'
   - dilemma: it doesn't always lead to equal or better performance.
On some systems and workloads, write performance is slightly reduced.
What about LZO?

B. do this with per directory XATTR
   - dilemma: the target directories don't exist at install time,
depending on whether the installation is rsync, rpm, or unsquashfs

C. do the install with '-o compres=zstd', then set XATTR post-install
   - dilemma: the installed files won't have XATTR set, only new files
inherit;  does a 'dnf update' overwrite files and therefore the XATTR
is not inherited, or are they new files and do inherit the XATTR?

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


(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

For reference, the above is mostly from the description in the RFE bug
attached to the feature's tracker bug. But I think it's best to have
most discussion here and leave the bug for implementing+testing the
implementation details.


Chris Murphy
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