Hi Steve, On Wed, Mar 21, 2018 at 12:40 AM Steve Langasek <steve.langa...@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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel