Under Docker 29's default image store, a 100MB container quota let 300MB through

The precondition on `--storage-opt size` is old and documented: it caps a container's writable layer only on overlay2 over XFS mounted with the `pquota` option ^[3]. The host in this test does not qualify, because its root filesystem is plain ext4 with no project quota mount option ^[2]. The graphdriver checks for that and stops the run with `--storage-opt is supported only for overlay over xfs with 'pquota' mount option` ^[4].

The backend is one daemon flag. Setting `"features": {"containerd-snapshotter": false}` selects the old path, and `docker info` then reports `Storage Driver: overlay2` instead of `overlayfs` with `driver-type io.containerd.snapshotter.v1` ^[10]. On the snapshotter side the same command is accepted, and a `dd` inside the container copied 314572800 bytes in 1.81 seconds ^[6]. Three times the stated cap, with no warning and no log line ^[1][7]. The author of the dev.to write-up attributes this to an unimplemented check: the containerd image store path does not validate that the backing filesystem supports a quota before accepting the option, where the graphdriver path does ^[9].

The speed result carries more conditions than the quota result. One host, one network path, one image: `node:22`, 8 layers, 1.64GB unpacked, pulled from a clean state with the local image removed each time and the backends alternated ^[11]. The graphdriver runs came later in the sequence, so a warm registry or proxy cache would have favoured the slower side ^[13]. With `max-concurrent-downloads` at 1, the gap is 10.5 seconds, about 37% ^[2]. Raising the limit to 8 moved the snapshotter to 15.0s and the graphdriver to 27.5s, widening the gap to about 45% ^[12][3].

Inside either backend, the concurrency setting barely moves. Going from 8 to 1 cost the snapshotter about 17% and the graphdriver about 3.5% ^[12]. Docker's own release notes record a bug, fixed in 29.7.0, where concurrent pull limits were not honoured on the snapshotter path, and 29.3.1 should have shown that as serialization ^[14]. The numbers show no such serialization. The author's conclusion from them is that unpacking layers into the filesystem dominates pull wall-clock time far more than the number of concurrent HTTP downloads does, at least on that network path ^[15]. For the 37% to transfer, your pulls have to be unpack-bound too.

Two limits on the quota finding are worth stating. The host was ext4, so the test does not cover whether the snapshotter honours `size` on XFS with `pquota`. And the daemon was 29.3.1, behind the 29.7.0 release that Docker's notes credit with graduating `--mount type=image` out of experimental; on 29.3.1 that mount type still prints `WARNING: Image mount is an experimental feature` ^[16][2]. The check that would settle either question on your own hosts is a write past the limit, inside a container, on the filesystem you actually run.