Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Kamil,

> Bohdan, could you build the same image in several configurations (the most likely candidates) and share them with us? (We can host them in our QA fedorapeople space, if needed). That would allow interested parties to test and benchmark the experience themselves.

I'll provide ISO images for testing at some point. One part of this change (https://pagure.io/pungi-fedora/pull-request/871#request_diff) was briefly included in the Rawhide compose for testing. This resulted in reduction of the DVD and BOOT.iso size by approximately ~24MiB without changing the compression parameters. The compose is available at the URI [1]. But due to the problem identified in anaconda's dracut module, the images were unbootable. I proposed a fix to the problem in https://github.com/rhinstaller/anaconda/pull/2820.


[1] https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200828.n.0/compose/Server/x86_64/iso/

On 01/09/2020 14:13, Kamil Paral wrote:
On Fri, Aug 28, 2020 at 12:55 AM Michel Alexandre Salim <michel@xxxxxxxxxxxxxxx> wrote:
On Thu, 2020-08-27 at 11:13 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
>
> == Summary ==
> Improve compression ratio of SquashFS filesystem on the installation
> media.
>
...
>
> Based on the results above, I'd suggest selecting the following
> ''optimal configuration'': XZ algorithm, with block size of 1MiB and
> without BCJ filter (plain xz -b 1M, without -Xbcj x86).
> On the right, you can see the impact of the compression algorithms on
> installation time.
>
Why XZ as opposed to, say, ZSTD?

Bohdan's preference seems to be to make the images smaller. I'm in the opposite camp. I'd like to keep the images roughly the same size (or smaller, but just a bit smaller, not as small as possible) and hugely speed up the installation instead. Which means zstd in one of the configurations. Each image is downloaded just once, but installed 1+ times. And with automation and all the CI work which Fedora and Red Hat invests a lot of effort into, it can be a hundred installations from a single image (without being bound to slow USB stick transfer speeds, as in the proposal). Of course, I'm biased.

Bohdan, could you build the same image in several configurations (the most likely candidates) and share them with us? (We can host them in our QA fedorapeople space, if needed). That would allow interested parties to test and benchmark the experience themselves.


_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
-- 
Bohdan Khomutskyi
RHEL Compose release engineer
EXD Software production
Red Hat
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux