So I was trying to update libseccomp last night, and I was able to
build it for everything except aarch64 on Rawhide because it says the
compiler can't build executables.
Looking a bit closer, it looks like the compiler stack is out of sync
again with annobin.
Is there anything that can be done to keep the compiler teams from
submitting gcc into rawhide without doing the required rebuild cycle
to make it so annobin works?
And we're going to have the same problem with clang now that annobin
grew a clang plugin, so I would want neither LLVM nor GCC to land in
Rawhide unless those teams are literally ensuring that annobin isn't
breaking the compiler afterward.
I'm personally very tired of having the compiler break so frequently
because of that plugin. Either some kind of mechanism to hold back GCC
builds until annobin works is implemented, or I'd much rather see the
whole thing go away. Obviously, you could just *bundle* annobin into
the GCC package and build it together to ensure it never broke, but
that option was discarded already.
Somebody fix it. ASAP.
真実はいつも一つ！/ Always, there's only one truth!
The change proposal has a 'compression option' and we kinda need to
- 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
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