Supporting LZ4 as initramfs compressor

[Balint Reczey]

Hi Steve,

On Wed, Mar 21, 2018 at 12:40 AM Steve Langasek
<steve.langasek at ubuntu.com> wrote:
>
> Hi Balint,
>
> On Mon, Mar 19, 2018 at 02:59:24PM +0000, Balint Reczey wrote:
>
> > Initramfs-tools uses gzip compression by default which served us well
> > for quite some time but LZ4 offers way faster decompression while
> > making a only slightly bigger initramfs files.
>
> When people have previously discussed lz4 on IRC as a possible choice for
> default compression algorithm, I had the impression that this was with the
> expectation that the resulting initramfs files would be *smaller* than with
> using gzip.
>
> (I think.  It happens that names for compression algorithms are remarkably
> unoriginal, so it's possible I've confused lz4 with another.)
>
> But your data shows that lz4-compressed initramfs is definitely larger than
> gzip, which means that there are tradeoffs here that should be fully
> examined.
>
> After all, an initramfs that's not compressed at all would take even less
> time to decompress at boot (0s) but would occupy more space.  But you aren't
> advocating for this, so there must be some reason you believe lz4 is more of
> a sweet spot than gzip?
>
>
> The first thing that I see missing from this analysis is the time it takes
> for the firmware/bootloader to load the initramfs into memory.  I know from
> experience that some bootloader filesystem drivers have quite poor
> performance; and the time spent loading the initramfs into memory will scale
> roughly linearly with the file size.  So any analysis of lz4 impact on boot
> speed needs to take this into account.  We should show that the overall
> bootspeed from bootloader to pid 1 has actually improved, and this should be
> measured with multiple bootloader driver implementations (across
> architectures; UEFI vs BIOS; possibly on multiple virtualization substrates
> vs. x86 bare metal).
>
>
> The second thing to consider is that, regardless of any improvements in our
> autoremoval of kernels, we have had some historical default sizing for /boot
> partitions in the installer which are now on the small side for even a fully
> correct kernel upgrade path.
>
> In trusty, the default (max) size for a /boot partition was 256M.  In
> xenial, it was 512M.  In artful, we have bumped this up to 768M with a
> minimum of 512M because of LP: #1716999.
>
> The actual space consumed by the static files in the 4.13.0-7-generic kernel
> in artful - not counting the current .efi.signed duplication which will
> hopefully go away soon - is just under 13MiB.  My bootloader here is 8MiB,
> but 10MiB is not out of the question in some configurations.  My initramfs
> is 52MiB rather than the 55MiB in that bug, but again 55MiB is plausible -
> and your own numbers seem to show 56MiB.
>
> That means that anyone who installed with trusty, has /boot as a separate
> partition, and has plymouth in the initramfs (such as for encrypted root
> disk, which would be a common reason to have a separate /boot) has already
> run out of space on their /boot while using gzip; so must already reinstall
> or switch to a non-default initrd compression algorithm on upgrade.  This
> can therefore be ignored for the choice between gzip and lz4 as default.
>
> Anyone who installed with xenial is borderline today with artful;
> 56*4+3*13+10 == 273MiB, which is more than xenial's minimum /boot size of
> 256MiB but less than the max of 512MiB.  So some number of users have a boot
> partition that's large enough to accommodate gzipped initrd, but will run
> out of space once you switch to lz4 (64*4+3*13+10 == 305MiB).  And those
> that don't run out of space immediately as a result of the switch to lz4
> would still run out of space sooner as the kernel size grows (since the
> kernel definitely seems to only grow over time with new drivers).
>
> Systems installed with artful or newer seem to still be fine for a while,
> with either gzip or lz4.
>
> So there's a decision to be made about whether we care about upgrades
> working with the default compression on systems installed with smaller boot,
> and for how long.  If we decide this shouldn't block switching the default
> compression, we also need to sort out how we will communicate this to
> affected users - and in particular, how to avoid problems on upgrade when
> the user runs out of disk space at the worst possible time.
>
>
> > Base on the results I plan adding LZ4 compression support to
> > initramfs-tools as requested in LP: #1488620 [1] in the next days
> > without setting it as default and I propose setting LZ4 as default for
> > 18.10.
>
> Since this is a non-default option and doesn't introduce any new
> dependencies, this seems fine.  It also doesn't seem urgent to me; in terms
> of the upgrade path, it doesn't need to be supported in 18.04 in order to
> consider making it the default in 18.10.

LZ4 compression is now available as a non-default option in Cosmic [2]
( \o/ :-) ).

Considering the potential problems with small boot partitions and even
more constrained embedded systems I'm not recommending making LZ4 as
the default, but making "auto" the default as discussed in [3] . Auto
would detect if there are space constraints and pick smallest (xz) or
fastest to boot (lz4) option.

Cheers,
Balint

[2] https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1488620/comments/8
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592519