> This difference is particularly noticeable with multiple images sharing the same base layers. With legacy storage drivers, shared base layers were stored once locally, and reused images that depended on them. With containerd, each image stores its own compressed version of shared layers, even though the uncompressed layers are still de-duplicated through snapshotters.<p>This seems like a really weird decision. If base images are duplicated for every image you have, that will add up quickly.
Docker already fills up my dev machines yet they decided for this insane solution:<p>> 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.<p>Why ?
Sounds like a straightforward time-space tradeoff: if you have the compressed layers sitting around when you need them, you can avoid the expense and time of compressing them.
Why would I need the compressed layers?
did you mean the first "compressed" to be "uncompressed" ?
I'm not sure about the fastest macbook disk access, but even with NVMe storage I've found lz4 to be faster than the disk. That is (it's hard to say this exactly correct) compressed content gets read/written FASTER than uncompressed content because fewer bytes need to transit the disk interface and the CPU is able to compress/decompress significantly faster than data is able to go through whatever disk bus you've got.
That will make Apple happy, all the people who didn't get a large enough disk when they purchased their laptops last time around are already struggling with local AI models.<p>It is shameful for apple to hard solder their disks. There is no benefit to the user<p>As we have seen with framework even the hard solder ram is not needed to get reasonable performance. At least let me expand my memory even if it doesn't perform as fast as on chip.
Docker v29 (released 2025-11) switched to using containerd for its image store for new installs.<p>This means `/var/lib/docker` is no longer "hermetic": images and container snapshots are located in `/var/lib/containerd` now.<p>More info about the switch: <a href="https://www.docker.com/blog/docker-engine-version-29/" rel="nofollow">https://www.docker.com/blog/docker-engine-version-29/</a><p>To configure this directory, see <a href="https://docs.docker.com/engine/storage/containerd/" rel="nofollow">https://docs.docker.com/engine/storage/containerd/</a>.
I noticed the change because I wanted to persist Docker-related data between container instantiations on IncusOS. I couldn't understand why the custom volume I had mounted on /var/lib/docker didn't contain the downloaded images.<p>To keep both /var/lib/{containerd,docker} in sync, I use a single ZFS dataset ("custom filesystem volume" in Incus parlance) and mount subpaths inside the container:<p><pre><code> incus storage volume create local docker-data
incus config device add docker docker disk pool=local source=docker-data/docker path=/var/lib/docker
incus config device add docker containerd disk pool=local source=docker-data/containerd path=/var/lib/containerd
</code></pre>
There are other ways to achieve the same of course.
Why not just use podman at this point?