Why does today's kernel update need half a gigabyte of disk space?

I got a notification of updates to Ubuntu 20.04. I always check the list of updates to decide how serious a backup I need to do before updating. Today's kernel update (5.13.0.28.31~20.04.15) needs half a gigabyte of extra disk space:

$ sudo apt upgrade 
...
The following NEW packages will be installed:
  linux-headers-5.13.0-28-generic linux-hwe-5.13-headers-5.13.0-28
  linux-image-5.13.0-28-generic linux-modules-5.13.0-28-generic
  linux-modules-extra-5.13.0-28-generic
The following packages will be upgraded:
  linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04
  linux-image-generic-hwe-20.04 linux-libc-dev
4 to upgrade, 5 to newly install, 0 to renove and 0 not to upgrade
Need to get 95.0 MB of archives.
After this operation, 508 MB of additional disk space will be used.

I know that Ubuntu allows several kernels to coexist, so this kernel must use fresh disk space rather than replacing existing software, but it still seems large. I've not kept notes, but I thought a kernel update was usually a couple of hundred MBs. Have I just never noticed the size of kernels before or is there something unusual about today's update?

There are a few of different things going on here, depending on where your curiosity lies...

Kernels updates are delivered as standalone packages, not simple upgrades

Most of your system is packaged in such a way that when an upgrade is extracted, it replaces the last version. Kernels are packaged with their version in the package name. This affords you the ability to fall back to a previous version if something goes wrong.

You don't need to keep the old kernels around. As soon as you know the new one works, you can remove the old ones. sudo apt autoremove will do this for you, but make sure the new version works first.

Kernels are big (and are getting bigger)

So we've established why installing an updated kernel takes up additional space, but why so much space?

Ubuntu ships a kernel built for a wide selection of hardware. Canonical wants it to Just Work™ when you plug things in. Every minor version has more drivers added to it. The rate of old drivers being removed is typically much slower.

So over time we expect the kernel to bloom in size. Bionic's 4.15.0-101.102 is roughly 60% the size of Focal's HWE 5.13.0. This is mostly expressed through having fewer modules especially in modules-extra.

I like to think of this as progress. Disk space and bandwidth is cheap for most of us, so prioritising driver support makes sense. I don't think what we're seeing here is abnormal.

But why are their packages so small? How does a 94MB download take up 508MB of disk space?

They compress [really] well. You can see this by downloading the packages and using a little scripting to expose their unpacked size.

• Get the packages: apt download linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04 linux-image-generic-hwe-20.04 linux-headers-5.13.0-28-generic linux-hwe-5.13-headers-5.13.0-28 linux-image-5.13.0-28-generic linux-modules-5.13.0-28-generic linux-modules-extra-5.13.0-28-generic
• Compare their "physical" size with their contents' size: for f in *.deb; do stat --printf="%5n\t%s\t" "$f"; dpkg -c $f; done

That's pretty raw at that point. You can scootch it into Calc to show totals and percentages:

Somewhat more than 508MB of disk space combined (before DKMS too) but perhaps you already had some of the packages downloaded. Either which way, you can see that some packages are massively bigger.

I want smaller Kernels!

And you can have them. Just looking down the modules-extra package contents, I can see hundreds of megabytes of things I don't need. Alas, there are some I do need though.

You can (fairly easily) build your own Kernels. There are build scripts (I'm currently using linux-tkg). It's 450MB on disk at the moment but I could run it though a helper like make localmodconfig to cut its built modules down to just the things currently loaded. This would cut out about 95% of the modules.

The problem with this approach is it takes CPU time, and my time to update it when there are updates. You're on your own. Most people are better off with the maintained kernel.

All of the above is absolutely true.

However part of the answer, (and why the above answers work), is based on the way Linux handles a "deleted" file - it doesn't really get deleted until everything using it has finished.

Example:
Assume an application, "Super Duper Text Editor", and also assume you have several windows open with text you are editing.

Additionally, assume an update to Super Duper Text Editor gets installed. Your existing editing sessions don't immediately get clobbered, they go away after you close them.

Like this:

1. You have several instances of the text editor open.
2. You update it.
   • The updater "unlinks" the directory entry to the old file, (or re-creates it), and adds a link to the new file, with the original directory entry marked as "deleted"
   • The existing links to your sessions remain until the existing sessions are closed.
3. All the new files are added, but the existing files that are still in use aren't destroyed because they're still in use.
4. Eventually, as you save work and close windows, the number of active links to the old files drops to zero. (remember, the directory's link was removed when the package was updated.)

When the number of links to a file drops to zero, the file is assumed to be "deleted" and that space is recovered for re-use by the filesystem and marked as available in the superblock and/or volume bitmap.

Eventually, (or especially after a reboot), all the old files have zero links and are fair game to be overwritten.

I am sure that there are details I have missed, but that's the general way it works.