[Git-commits] [grml/grml-live] fada6d: Use 1m as new default squashfs block size

[Michael Prokop]

  Branch: refs/heads/master
  Home:   https://github.com/grml/grml-live
  Commit: fada6dea0ffacc5ee41b1ae0144197f233e4ca87
      https://github.com/grml/grml-live/commit/fada6dea0ffacc5ee41b1ae0144197f233e4ca87
  Author: Michael Prokop <mika at grml.org>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M etc/grml/grml-live.conf
    M grml-live

  Log Message:
  -----------
  Use 1m as new default squashfs block size

The default block size of mksquashfs is 128k, while we used 256k since 2009.
When increasing the block size further, we increase build time, but also
decrease the file size (and therefore the resulting ISO).

Nowadays rotating media (CD/DVD) aren't so much in usage anymore, while
(USB) flash drives and direct ISO boot (both from disk as well as via
OOB management) are way more common. Latency maybe is no longer so
relevant as it used to be, so let's see if this turns out to be a
problem. On the other side smaller ISOs decrease download times as well
as disk usage (esp. when used as /boot/grml via grml-rescueboot).
Overall it is a trade off that's worth consideration, let's give it a try.

Some non-scientific benchmarks give the following build times:

* block size 256k: 2min 19sec, 383MB
* block size 1m:   3min 30sec, 363MB

Buffer/cache memory usage of the booted ISO slightly increases (91MB
used and 170MB buff/cache with block size 1m, vs. 94MB used and 143MB
buff/cache with block size 256kb), but might be neglectable. (And once
again, this was another non-scientific benchmark.)

Further options that might be worth consideration are 1) -Xdict-size
(while -Xdict-size 100% is the default already, so noting really to do
for us here), and 2) `-Xbcj x86`, which further increases compression
time, but also has a bit of savings.

FTR, Jonathan Carter did some benchmarks related to squashfs in 2015, see
https://jonathancarter.org/2015/04/06/squashfs-performance-testing/.
And Fedora is considering usage of `-b 1M -Xdict-size 1M -no-recovery`
(which would be identical to what we have, note that -no-recovery
doesn't seem to influence file size), see
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS

Thanks: Mihai Moldovan <ionic at ionic.de>