7:35 p.m.
On Thu, Dec 10, 2015 at 11:47 AM, Jason Brooks <jbrooks(a)redhat.com> wrote:
You can ignore docker-storage-setup and edit
/etc/sysconfig/docker-storage
yourself.
OK I've done "systemctl disable docker-storage-setup"
Here's what it looks like from the f23 vagrant box:
DOCKER_STORAGE_OPTIONS=-s devicemapper --storage-opt dm.fs=xfs --storage-opt
dm.thinpooldev=/dev/mapper/atomicos-docker--pool --storage-opt
dm.use_deferred_removal=true
Short version: This works. Docker service starts, no errors, and it's
not using a loopback device.
Followup question: Does Docker directly use a thin pool without
creating (virtual size) logical volumes? Because I don't see any other
LV's created, and no XFS filesystem appears on the host using the
mount command. And yet I see XFS mount and umount kernel messages on
the host. This is sort of an esoteric question. However, I have no
access to container files from the host like I can see inside each
btrfs subvolume when btrfs is the backing method. And that suggests
possibly rather different backup strategies depending on the backing.
Long version of the question:
# systemctl stop docker
Copied generic docker-storage and edited as follows:
DOCKER_STORAGE_OPTIONS=-s devicemapper --storage-opt dm.fs=xfs
--storage-opt dm.thinpooldev=/dev/mapper/vgfedora-docker--pool
--storage-opt dm.use_deferred_removal=true
# systemctl start docker
Dec 10 13:05:02 f23a.localdomain systemd[1]: Starting Docker
Application Container Engine...
Dec 10 13:05:06 f23a.localdomain docker[1695]:
time="2015-12-10T13:05:06.377269077-07:00" level=info msg="Firewalld
running: false"
Dec 10 13:05:06 f23a.localdomain docker[1695]:
time="2015-12-10T13:05:06.791189262-07:00" level=info msg="Default
bridge (docker0) is assigned with an IP address 172.17.0.1/16. Daemon
option --bip can be used to set a preferred IP address"
Dec 10 13:05:07 f23a.localdomain docker[1695]:
time="2015-12-10T13:05:07.572415354-07:00" level=info msg="Loading
containers: start."
Dec 10 13:05:07 f23a.localdomain docker[1695]: ......
Dec 10 13:05:07 f23a.localdomain docker[1695]:
time="2015-12-10T13:05:07.576094399-07:00" level=info msg="Loading
containers: done."
Dec 10 13:05:07 f23a.localdomain docker[1695]:
time="2015-12-10T13:05:07.576663930-07:00" level=info msg="Daemon has
completed initialization"
Dec 10 13:05:07 f23a.localdomain docker[1695]:
time="2015-12-10T13:05:07.576770908-07:00" level=info msg="Docker
daemon" commit=f7c1d52-dirty execdriver=native-0.2
graphdriver=devicemapper version=1.9.1-fc23
Dec 10 13:05:07 f23a.localdomain docker[1695]:
time="2015-12-10T13:05:07.577004141-07:00" level=info msg="API listen
on /var/run/docker.sock"
Dec 10 13:05:07 f23a.localdomain systemd[1]: Started Docker
Application Container Engine.
host# docker pull fedora
host# docker images
REPOSITORY TAG IMAGE ID CREATED
VIRTUAL SIZE
fedora latest 597717fc21bd 2 weeks
ago 204 MB
So that all works, and then also the thin pool data% is growing after
each step, according to lvs. But there is no logical volume, no file
system.
host# docker run -i -t fedora /bin/bash
host# mount | grep xfs
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
host# mount | grep ext
/dev/sda3 on /boot type ext4 (rw,relatime,seclabel,stripe=4,data=ordered)
It's working. But is Docker directly using the thin pool without
creating a thin logical volume and file system? That's unexpected.
host# lvs
LV VG Attr LSize Pool Origin Data% Meta%
Move Log Cpy%Sync Convert
docker-pool vgfedora twi-aotz-- 250.00g 0.11 0.53
host# docker pull ubuntu
[...snip pull output...]
-bash-4.3# lvs
LV VG Attr LSize Pool Origin Data% Meta%
Move Log Cpy%Sync Convert
docker-pool vgfedora twi-aotz-- 250.00g 0.20 0.63
Yeah, it seems to directly use the thin pool without create a virtual
size LV first. Kernel messages show a bunch of items like this:
[ 7818.790685] XFS (dm-4): Mounting V5 Filesystem
[ 7819.038211] XFS (dm-4): Ending clean mount
[ 7834.219132] XFS (dm-4): Unmounting Filesystem
So it's using XFS on something, that isn't appearing in mount on the
host or in the container. And multiple containers all appear to use
XFS on the same device mapper device (dm-4) which does not appear on
the host in the /dev/ directory. So this is really... obscured.
--
Chris Murphy