From Fedora Project Wiki
m (Bkhomuts moved page Fedora Project Wiki:Changes/OptimizeSquashFS to Changes/OptimizeSquashFS: Moving to (Main). I wasn't able to find this category, because of my browser dimensions :))
(Change rejected by FESCo)
 
(5 intermediate revisions by 2 users not shown)
Line 43: Line 43:


== Current status ==
== Current status ==
* Targeted release: [[Releases/33 | Fedora 33 ]]  
[[Category:ChangePageIncomplete]]
[[Category:SelfContainedChange]]
 
* Targeted release: [[ Releases/33 | Fedora 33 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 52: Line 55:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* FESCo issue: [https://pagure.io/fesco/issue/2470 #2470]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
* Pull requests to the Fedora Release Engineering:
https://pagure.io/pungi-fedora/pull-request/871</br>
https://pagure.io/pungi-fedora/pull-request/872


== Detailed Description ==
== Detailed Description ==
Line 201: Line 209:
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
-->
[[Category:ChangeAnnounced]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SystemWideChange]]

Latest revision as of 14:52, 9 September 2020


Reduce installation media size by improving the compression ratio of SquashFS filesystem

Summary

Improve compression ratio of SquashFS filesystem on the installation media.

Owner

Current status

  • Targeted release: Fedora 33
  • Last updated: 2020-09-09
  • FESCo issue: #2470
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>
  • Pull requests to the Fedora Release Engineering:

https://pagure.io/pungi-fedora/pull-request/871
https://pagure.io/pungi-fedora/pull-request/872

Detailed Description

As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is compressed with default block size of mksquashfs. The default block size is 128k. Additionaly, lorax sets BCJ filter depending on the architecture. Those parameters can be adjusted which will lead to a better compression ratio and/or reduction of the CPU usage at build time.

Comparison of different SquashFS compression options and their impact on the time required to generate the SquashFS filesystem

This is simple to achieve. Recently, Lorax has gotten support for adjusting the compression options for mksquashfs via the configuration file. The file should be altered as following:

[compression]
bcj = no
args = -b 1M -Xdict-size 1M -no-recovery

Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively; bcj -- branch-call-jump filter.

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.

Different compression options and their impact on the installation time

As can be seen from the picture on the right hand side, selecting 'plain xz -b 1M configuration' has minimal impact on the installation time and CPU usage during the installation. The compression will result in +6.51% or, in real terms, +24.94s additional installation time, compared to the savings of 142 MiB on the installation media, refer to the documentation section to download the ISO images. This increase in installation time will be compensated by the change in the installer: https://github.com/rhinstaller/anaconda/pull/2292 I noticed, that even with maximum compression, CPU is not fully utilized during installation.

Alternative compression algorithms and the resulting filesystem size

Benefit to Fedora

  • Reduction of the installation media size and the cost of storing and distributing Fedora.
  • Reduction of the CPU usage at build time. Depending on which compression parameters chosen.

Scope

  • Proposal owners:

The build environment should have support for adjusting the Lorax configuration file and -squashfs-only parameter. Lorax is a program that produces the LiveOS/squashfs.img file on the installation media.

One of the ways to enable such customization is to introduce support in Pungi to pass -c option to Lorax.

  • Other developers:

The pungi utility should support passing the custom configuration file location to the Lorax utility. This option should apply during buildInstall phase of pungi.

  • Release engineering: [1]
  • Policies and guidelines: Not required.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

This change comes at a cost of higher memory usage during the installation. Based on my personal estimations, this should not be the issue. Since the decompression should require up to 1MiB per thread. At the moment, the decompression of SquashFS is single-threaded.

N/A (not a System Wide Change)

How To Test

mkdir -p /mnt/new /mnt/old
sudo mount -o loop,ro FedoraInstallationOld.iso
sudo mount -o loop,ro FedoraInstallationNew.iso
ls -l /mnt/{new,old}/LiveOS/squashfs.img

And then calculate the size difference.

User Experience

  • Decreasing the installation image size will reduce cost of mirroring and storing Fedora installation images.
  • Decreasing the installation image size will reduce the download time.
  • Increasing the block size on the current configuration with EXT4 file system, should increase latency while accessing the EXT4 filesystem. The exact impact is to be evaluated.
  • The impact of latency will be reduced, if the plain SquashFS option is be choosen.

Dependencies

Pungi, a utility that builds the compose, should include new functionality mentioned above. Alternatively, the /etc/lorax/lorax.conf should be altered in the environment where Lorax is running.

Contingency Plan

N/A

Documentation

https://pagure.io/releng/issue/9127.
mksquashfs(1)
lorax(1)
https://docs.pagure.org/pungi
Select ISOs can be downloaded at https://khomutsky.com/fedora-dvd/
Spreadsheet pictured above File:Comparison Table SquashFS.ods Multi-core decompression of SquashFS merge request

Release Notes