What's stored in com.apple.container/snapshots and how to prune it?

[ole]

I was looking at the storage used by container and found that the majority of the storage is in ~/Library/Application Support/com.apple.container/snapshots. On my system:

$ container --version
container CLI version 1.1.0 (build: release, commit: unspeci)

$ cd ~/Library/Application\ Support/com.apple.container/
$ /usr/bin/du -h -d 1 . | sort --sort=human-numeric
  0B	./builder
  0B	./containers
  0B	./volumes
4.0K	./apiserver
8.0K	./networks
 12K	./plugin-state
 14M	./kernels
8.1G	./content
 31G	./snapshots
 40G	.

The 8.1 GB on my machine in ./content seem to correspond to the actual blobs that make up the images I have installed, and that number makes sense to me as it's roughly what I'd expect my images to take up in disk space (judging from container image ls --verbose).

But what is stored in ./snapshots? 31 GB is massive and I'd love to have that storage back if I can. I tried container prune, but that just says "Reclaimed Zero KB in disk space".

I currently have no actual containers (neither running nor stopped) and no container machines:

$ container ls --all
ID  IMAGE  OS  ARCH  STATE  IP  CPUS  MEMORY  STARTED

$ container machine ls
NAME  CREATED  IP  CPUS  MEMORY  DISK  STATE  DEFAULT

[ole]

Trying to answer my own question: container system df does list the size of my images as 42 GB, rather than the approx. 8–9 GB listed by container image ls --verbose:

$ container system df
TYPE           TOTAL  ACTIVE  SIZE      RECLAIMABLE
Images         15     0       42,43 GB  42,43 GB (100%)
Containers     0      0       0 B       0 B (0%)
Local Volumes  0      0       0 B       0 B (0%)

So I assume the uncompressed(?) size of my images on disk is in fact 42 GB, and this data is somehow distributed among the ./content and ./snapshot directories. I assume the only way to reduce the amount of data used by container would be to delete one or more images.

I do find it confusing that container image ls --verbose doesn't display the actual size on disk for each image, which makes it hard to predict the effect on free disk space that installing or deleting a particular image might have.

I acknowledge that this is a hard problem, though, given that multiple images may share one or more layers. But even accepting this, I would expect that an image that's listed with a size of (say) 2.5 GB in container image ls --verbose would never exceed this size on disk, at least when no container using this image exists. Apparently this isn't true.