> The containerd image store uses more disk space than the legacy storage drivers for the same images. This is because containerd stores images in both compressed and uncompressed formats, while the legacy drivers stored only the uncompressed layers.
Why ?
It still bothers me that the fastest most performant computer I have access to is almost always my laptop, and that by a considerable margin.
Someone should do some lz4 vs. ssd benchmarks across hardware to make my argument more solid and the boundaries clear.
But yes on the extreme end absolutely there's a point where lz4 stops making sense, but also most of us aren't trying to max out a 128 core postgres server or whatever.
Also looking at block-based content store so that blocks can be deduped across images.
Old docker discarded the compressed bits but kept some metadata about the the so it can at least recreate the tar.
It also recreated the manifest o push.
(As others said, compression is deterministic for the same algorithm, parameters and input data)
Tar isn't related here though, we're talking about compression not archival formats
Just in case - I'm always amazed how many Docker users don't know about the prune command for cleaning up the caches and deleting unused container images and just slowly let their docker image cache eat their disk.
docker image prune -a --filter "until=24h"
Buildkit isn't changing behavior here. Internally in docker there is a shim to make the legacy storage behave like containerd snapshotters (as well as it can, anyway--not perfect due to hard to resolve issues in the old storage). But it still kept both the compressed and uncompressed versions of images.