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. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel