On systems that supports reflinking (i.e. btrfs) this means the dummy
backend is much faster at copying files and will be sharing file data in
a CoW fashion.
On my (btrfs) system this makes "docker run ubuntu echo hello world" go
from about 3 seconds to about 1 second. Not instant, but clearly better.
cp --reflink=auto is availible since coreutils 7.5 (around 2009), so this
seems pretty ok to rely on.
cp is also better at preserving file metadata than tar, so for instance
it will copy xattrs.
This moves Driver.Size() to Differ.DiffSize(), removing the empty
implementations in devmapper and dummy, and renaming the one in aufs.
Then we fall back to a container.Changes() implementation in the non-aufs
case.
We place the actual image/containers in the "rootfs" directory, which
allows us to have other data in the toplevel directory in the mount.
For starters, this means the "lost+found" directory from mkfs will
not always be in your container/image.
Secondly, we can create a file "id" in the toplevel dir which is not
visible from the container. This is useful because it allows us to map
back from the device fs to the container if something goes wrong with
the devicemapper metadata.
It makes no sense to use the aufs or devicemapper drivers for volumes.
The aufs one is perhaps not a big problem, but the devicemapper one
certainly is. It will be unnecessarily using a dm
blockdevice-over-loopback with a limited size base FS.
This just hardcodes the driver to be the dummy, perhaps in the future
we can have other drivers that make sense for the volumes.
This adds a generic Status call in the Driver api and
implements if for the devicemapper backend.
The status is an array of key/value strings rather than a map so that
we can guarantee some static order of the docker info output.