Context
A container's apparent size is only one part of its storage footprint. Writable-layer changes, shared image layers, logging-driver files, volumes, and build cache have different owners and cleanup rules. A small writable layer does not prove that its logs are small, and summing virtual image sizes can overcount shared data.
Prerequisites are the affected Docker host context, container names, storage configuration, and permission to inspect Docker resources. The commands below are read-only. Avoid broad prune commands or direct edits beneath Docker's storage directory while the source of growth is still unknown.
1. Inventory the storage categories
docker system df -v
docker ps --size
docker container inspect --size catalog
The container name is illustrative. Compare writable size with virtual size and inspect the resource inventory. Shared image content should not be counted repeatedly as though every container owns a separate full copy. Also note that these summaries do not represent every byte of driver-managed logs or mounted storage.
Read the storage-driver configuration through supported Docker inspection. Not every installation uses the same layer implementation or image store, so an overlay2-specific assumption may be wrong. Diagnose the categories first; apply driver-specific reasoning only after identifying the actual backend.
2. Inspect writes and mount boundaries
docker container diff catalog
docker container inspect --format '{{json .Mounts}}' catalog
docker container inspect --format '{{json .HostConfig.LogConfig}}' catalog
Review changed paths and the mount map. A path under a volume or bind mount belongs to a different storage lifecycle from the container's writable layer. Determine whether application output is intended persistent data, a bounded temporary file, or an accidental duplicate.
For an explicitly illustrative example, an export process writes temporary archives under /tmp while its intended persistent output is mounted at /exports. The writable layer grows even though the volume has ample capacity. The correction belongs in the application's output and temporary-file handling, not in an image cleanup job.
3. Check logging separately
Inspect the configured logging driver and its options. Review the application's log rate and retention expectations. Docker's documented json-file default can grow without rotation unless configured otherwise; other drivers have their own storage and delivery behavior. Changing a daemon default does not establish that existing containers have adopted a new setting.
Use Docker-supported log access or your centralized logging system. Do not truncate or remove driver-managed log files directly as an exploratory fix. Such files are managed by the daemon, and manipulating them outside the supported interface can produce unexpected behavior.
Match growth to the responsible owner
| Observation | Likely category | Correction to review |
|---|---|---|
| SizeRw grows with temporary output | Writable layer | Application path and temporary-file lifecycle |
| Layer looks small, log storage grows | Logging driver | Rotation, verbosity and retention |
| Named volume contains growing business data | Persistent storage | Application retention and capacity |
| Unused build records dominate inventory | Build cache | Scoped builder-cache maintenance |
Image-layer growth can also reflect copy-on-write behavior: modifying an existing image file may create writable-layer data. Avoid repeatedly changing large packaged files at runtime when a different application layout is appropriate.
Verify the correction and operating procedure
Review a narrowly scoped application, mount, logging, or cache-policy change. Validate it on a representative test container before replacing production instances. Observe the relevant category over a complete workload cycle and confirm that required logs and business data remain accessible.
Maintain a storage SOP with container owners, persistent mounts, temporary paths, log-driver settings, and authorized cleanup scopes. Monitor writable growth, logging storage, volume capacity, and builder-cache consumption as distinct signals. This gives an operator a specific action to take instead of treating all Docker-associated bytes as disposable.
Explore Clouvenix docker consulting for implementation and operational handover.