From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] linux-firmware: Compress firmware on disk Date: Thu, 24 Mar 2022 11:13:10 +0000 Message-ID: <72002BB1-518F-4746-B33F-82571136C543@ipfire.org> In-Reply-To: <38a58e63-69ab-f901-b171-4f7e5358347b@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1242352109412418121==" List-Id: --===============1242352109412418121== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Oh, this would be entirely linux-firmware since the last nightly build genera= ted an update for x86_64 of 7.8 MiB. I find it very interesting to see that Zstandard is so much better at recompr= essing this. We use XZ for the core update, but the distribution image in the= ISO file is compressed using Zstandard. 286 MiB is way too large and absolutely not worth it. I will test a couple of things and will then get back to you. Best, -Michael > On 24 Mar 2022, at 10:55, Peter M=C3=BCller wr= ote: >=20 > Hello Michael, >=20 > well, contrary to your expectation, shipping the compressed linux-firmware = leads to an way too big update: >=20 > $ cat ./install/packages/meta-core-upgrade-166 > Name: core-upgrade > Summary: IPFire Core Update > ProgVersion: 2.27 > Release: 166 > Size: 299315200 > Dependencies:=20 > File: core-upgrade-2.27-166.ipfire > Services:=20 > $ ls -lah ./install/packages/core-upgrade-2.27-166.ipfire > -rw-r--r-- 1 root root 286M 24. Mar 10:43 ./install/packages/core-upgrade-2= .27-166.ipfire >=20 > I do not have the figure ready how much of that 286 MByte are caused by lin= ux-firmware, but > it has to be way more than 100 MBytes. Otherwise, Core 166 would have been = to big already, which > I doubt when looking at the currently included filelists. >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 >=20 >> Hello, >>=20 >> So Peter has merged this patch now and it has resulted in an increase of a= bout 70M of the ISO image. This is expected since we are now compressing ever= ything individually which will give us a worse compression ratio. >>=20 >> I assume that the updater would grow in a similar size which is probably a= cceptable to me. >>=20 >> Since we suffer from bloated Core Updates, I wanted to double-check with e= verybody that this is okay for everybody else, too. >>=20 >> Best, >> -Michael --===============1242352109412418121==--