Thanks everyone for your comments. These are all valid concerns.
I filed a new change proposal at
I'll run more benchmarks, including using Zstd compression algorithm, and
will post results.
Hopefully this weekend, I'll also try to measure the impact of the
compression, block size versus installation time.
Also, the decompression of SquashFS is currently happening in single
thread. This could be changed with CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU
kernel build-time configuration option. I'll file a new change proposal for
it, along with benchmarks.
On Thu, Jan 9, 2020 at 11:13 AM Lukas Ruzicka <lruzicka(a)redhat.com> wrote:
> Why stacked images? Consider a single base.img that's maybe 1G, and
> now you don't have to do separate composes for server, cloud, GNOME,
> KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps,
> including expensive steps like compressing the same things over and
> over again. Just do a 'dnf group install' tacked onto that base.img,
> the work being done is custom for that output, rather than repetitive.
> Not complicated. It would be fast enough that the high level variants
> could be composed on demand. Seconds. It'd be fast enough to queue it
> for download within the hour.
Well, I would like that.
> Chris Murphy
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
FEDORA QE, RHCE
612 45 Brno - Královo Pole
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Bohdan Khomutskyi, RHCE
Release configuration management engineer, PnT DevOps
Red Hat Czech s.r.o
T: +420532270289 IRC: bkhomuts