On Sun, Jan 19, 2020 at 8:41 AM Bohdan Khomutskyi <bkhomuts(a)redhat.com> wrote:
Thanks everyone for posting feedback.
More benchmarking results are available at
, including the
'plain' SquashFS filesystem.
After performing the tests, I personally recommend to use xz compression with 1MiB block
size, without bcj, on a 'plain' squash filesystem -- this will lead to a reduction
of 142MiB on the ISO, compared to the stock Fedora 31 Workstation x86_64 image.
Alternative compression options, such as Zstd, are also mentioned in the change proposal.
Thanks for all the tests.
While I see the meaningfully reduced CPU hit of xz compressed images,
the proposal leaves a lot of performance improvement on the table by
not also enabling zstd as an option in the compose process. The tests
show zstd results, but the proposal doesn't mention zstd at all.
In particular for Workstation ISO, the CPU hit isn't worth the size
savings for regular users, let alone the recurring hit for releng
composes and QA's automated installation tests. It's a lot of CPU burn
at both ends of the candle, for not a lot of size savings. I'm not
convinced it's worth the extra hit on the create side for Zstd level
22, compared to Zstd 15 or 17.
I admit I'm biased toward the two endpoints: create and consume, not
distribution ,i.e the mirror donors. Their storage and bandwidth
concerns were evaluated with the RPM change from xz to zstd. So I'm
mystified by the bias for image size.
Anyway, I approve of the change but disappointed if it really doesn't
let Fedora release engineering the ability to choose (possibly based
on image type - maybe there's some benefit to using xz for raw and