Hi,
I’m using debian jessie with docker-engine (1.11) from apt.dockerproject.org
I’m having some disk performance issues on bind volumes and was exploring a path to upgrade the linux kernel and the storage driver (currently aufs). I might file a bug about the performance degradation on what should be a bind mount with little overhead.
When get linux-kernel 4.3 from debian backports and reboot on that, I don’t have aufs so docker service won’t start until I move /var/lib/docker/aufs/ out of the way. It then starts with devicemapper as a volume driver.
To migrate images I can do some docker export and docker import after rebooting. For the running instances I could do some docker save and docker import after rebooting (but since I’m running my instances from docker-compose, if my data is in place, they should be fine).
for img in
docker images | awk '$1 != "REPOSITORY" { print $1 }' | sort | uniq; do echo $img ; docker save $img | gzip - > $img.tar.gz ; done
then
for i in *.tar.gz; do docker import $i ${i/.tar.gz/}; done
My problem is for the data volumes. Right now I’m not using named data volumes, but that could be part of the solution I guess. After the reboot my /var/lib/docker/volumes is intact (and docker volume ls shows them).
Is there a smart way to reconnect the old volume ids to the new docker instances ? I was planning to write a script that would list instance names with volume ids while still on the 3.16 kernel and then after rebooting scripting a mv of those volume ids to the new ids before restarting my new docker instances.
Not that it matters, but the data is postgres & elasticsearch.