From c1b7b2827afa89c411271eb144d978e129fb2e42 Mon Sep 17 00:00:00 2001 From: Claude Docs Agent Date: Tue, 24 Mar 2026 13:02:31 +0100 Subject: [PATCH 1/2] docs: fix incorrect claim about compressed layer deduplication in containerd image store (fixes #24476) --- content/manuals/engine/storage/containerd.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/manuals/engine/storage/containerd.md b/content/manuals/engine/storage/containerd.md index c382e36577a..47338ef8009 100644 --- a/content/manuals/engine/storage/containerd.md +++ b/content/manuals/engine/storage/containerd.md @@ -55,12 +55,12 @@ each layer occupies more space. The compressed format enables faster pulls and pushes, but requires additional disk capacity. 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. The -compressed storage adds overhead proportional to the number of images using -those layers. +same base layers. Like legacy storage drivers, the containerd image store +deduplicates shared layers: if two images reference the same layer, that +layer's compressed blob is stored once in the content store, identified by +its digest. The overhead compared to legacy drivers is not duplication of +shared layers, but the dual storage of each unique layer: one compressed copy +in the content store and one unpacked copy in the snapshotter. If disk space is constrained, consider the following: From 1c906d95e949d0bda93b572175830ae3a4f92b98 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Wed, 25 Mar 2026 12:11:34 +0100 Subject: [PATCH 2/2] docs: remove contradictory paragraph from containerd disk space section MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The paragraph opened with "This difference is particularly noticeable with multiple images sharing the same base layers" — but then went on to explain that shared layers are deduplicated just like with legacy drivers. The opening sentence contradicts the explanation: since deduplication applies equally, there is nothing particularly noticeable about the shared-layer case. Remove the paragraph. The dual-storage overhead per unique layer is already explained in the preceding paragraph. Per review comment from mike-sul. Co-Authored-By: Claude Sonnet 4.6 --- content/manuals/engine/storage/containerd.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/content/manuals/engine/storage/containerd.md b/content/manuals/engine/storage/containerd.md index 47338ef8009..16075c3f6e4 100644 --- a/content/manuals/engine/storage/containerd.md +++ b/content/manuals/engine/storage/containerd.md @@ -54,14 +54,6 @@ from the registry) and also extracts them to disk. This dual storage means each layer occupies more space. The compressed format enables faster pulls and pushes, but requires additional disk capacity. -This difference is particularly noticeable with multiple images sharing the -same base layers. Like legacy storage drivers, the containerd image store -deduplicates shared layers: if two images reference the same layer, that -layer's compressed blob is stored once in the content store, identified by -its digest. The overhead compared to legacy drivers is not duplication of -shared layers, but the dual storage of each unique layer: one compressed copy -in the content store and one unpacked copy in the snapshotter. - If disk space is constrained, consider the following: - Regularly prune unused images with `docker image prune`