Moby: 장치 매퍼가 제거 된 이미지에서 여유 공간을 해제하지 않습니다.

에 만든 2013년 12월 12일 · 206코멘트 · 출처: moby/moby

Docker는 docker info 를 통해 이미지가 삭제 된 후 공간을 확보했다고 주장하지만 데이터 파일은 이전 크기를 유지하고 장치 매퍼 스토리지 백엔드 파일에 할당 된 스파 스 파일은 더 많은 확장 영역으로 제한없이 계속 증가합니다. 할당됩니다.

Ubuntu 13.10에서 lxc-docker를 사용하고 있습니다.

Linux ergodev-zed 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

이 일련의 명령은 문제를 나타냅니다.

docker pull stackbrew/ubuntu:13.10 하면 공간 사용량이 docker info 보고되었습니다.

Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-252:0-131308-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb
WARNING: No swap limit support

그리고 docker pull stackbrew/ubuntu:13.10 :

Containers: 0
Images: 3
Driver: devicemapper
 Pool Name: docker-252:0-131308-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 413.1 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.8 Mb
 Metadata Space Total: 2048.0 Mb
WARNING: No swap limit support

그리고 docker rmi 8f71d74c8cfc 후에 다음을 반환합니다.

Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-252:0-131308-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb
WARNING: No swap limit support

유일한 문제는 데이터 파일이 stat 당 414MiB (849016 512 바이트 섹터 블록)로 확장되었다는 것입니다. 해당 공간 중 일부는 이미지가 삭제 된 후 제대로 재사용되지만 데이터 파일은 축소되지 않습니다. 그리고 어떤 신비한 조건 (아직 재현 할 수 없음)에서 재사용조차 불가능한 291.5MiB가 할당되었습니다.

설치된 이미지가 0 개일 때 내 dmsetup ls 은 다음과 같습니다.

# dmsetup ls
docker-252:0-131308-pool        (252:2)
ergodev--zed--vg-root   (252:0)
cryptswap       (252:1)

그리고 데이터 파일의 du 는 다음을 보여줍니다.

# du /var/lib/docker/devicemapper/devicemapper/data -h
656M    /var/lib/docker/devicemapper/devicemapper/data

Docker가 공간을 회수하도록하려면 어떻게해야하며 이미지가 제거 될 때 Docker가 자동으로이 작업을 수행하지 않는 이유는 무엇입니까?

arestoragdevicemapper exexpert kinbug

출처

AaronFriel

👍5 😕1

가장 유용한 댓글

이 오래된 쓰레드를 다시 부활시키는 것을 매우 꺼려하지만,이 문제가 발생하는 기존 컴퓨터에서이 문제를 해결하는 방법에 대한 의미있는 조언이 아직 없습니다.

이것은 tldr에서 나의 최선의 노력입니다. 전체 스레드에 대해; 이 스레드를 찾는 다른 사람들에게 도움이되기를 바랍니다.

발생한 문제

귀하의 볼륨에는 /var/lib/docker 상당한 (그리고 증가하는) 공간이 있으며 ext3를 사용하고 있습니다.

해결

당신은 운이 없습니다. 파일 시스템을 업그레이드하거나 하단의 blowing docker away 를 참조하십시오.

발생한 문제

귀하의 볼륨에는 /var/lib/docker 있는 상당한 (그리고 증가하는) 공간이 있고 ext3를 사용하지 _ 않고 _ (예 : 현재 xfs 또는 ext4를 사용하는 시스템)

해결

표준 Docker 명령을 사용하여 장치의 공간을 확보 할 수 있습니다.

http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/ 읽기

다음 명령을 실행하십시오.

docker volume ls
docker ps
docker images

목록에 아무것도 없으면 하단의 blowing docker away 를 참조하십시오.

오래된 오래된 이미지, 사용되지 않은 컨테이너 등이 보이면 다음을 사용하여 수동 정리를 수행 할 수 있습니다.

# Delete 'exited' containers
docker rm -v $(docker ps -a -q -f status=exited)

# Delete 'dangling' images
docker rmi $(docker images -f "dangling=true" -q)

# Delete 'dangling' volumes
docker volume rm $(docker volume ls -qf dangling=true)

이것은 devicemapper에서 숨겨진 컨테이너 공간의 대부분을 회수해야합니다.

도커를 날려 버리다

작동하지 않았습니까? 당신은 운이 없습니다.

이 시점에서 가장 좋은 방법은 다음과 같습니다.

service docker stop
rm -rf /var/lib/docker
service docker start

이것은 모든 도커 이미지를 파괴합니다. 이 작업을 _ 전에 _ 유지하려는 항목을 내 보내야합니다.

궁극적으로 https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production; 그러나 이것이이 스레드를 찾는 다른 사람들에게 도움이되기를 바랍니다.

위의 조언을 사용하는 데 문제가있는 경우 발생한 문제를 구체적으로 해결하고이 문제에 연결 하는 새 티켓 을

shadowmint 에 2016년 10월 27일

👍79 ❤6

모든 206 댓글

+1,이 주제에 대한 토론을 듣고 싶습니다. 지금까지 내 전략은

무엇을 만들거나 당기는 지 조심하세요.
/ var / lib / docker : neutral_face :

@AaronFriel , 어떤 버전의 Docker를 사용하고 있습니까? 0.7.1?

vreon 에 2013년 12월 12일

👍1

/ cc @regilero (링크는 # 2276에도 있음)

kiorky 에 2013년 12월 12일

새로운 / var / lib / docker에서 시작 :

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
292M -rw-------. 1 root root 100G Dec 12 17:29 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root   89 Dec 12 17:29 /var/lib/docker/devicemapper/devicemapper/json
732K -rw-------. 1 root root 2.0G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

그런 다음 docker가 busybox를 가져온 후 약간 성장했습니다.

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
297M -rw-------. 1 root root 100G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root  181 Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/json
756K -rw-------. 1 root root 2.0G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 1
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 296.6 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

docker rmi busybox는 파일을 더 크게 만들지 _ 않지만 _ devicemapper 풀에서 공간을 확보합니다.

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
298M -rw-------. 1 root root 100G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root   89 Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/json
772K -rw-------. 1 root root 2.0G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

이미지를 다시 다운로드하면 루프백 파일이 커지지 않습니다.

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
298M -rw-------. 1 root root 100G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root  181 Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/json
772K -rw-------. 1 root root 2.0G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 1
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 296.6 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

따라서 Thinp 장치가 블록을 폐기 할 때 루프백 파일을 재분할하지 못하는 것 같습니다.

alexlarsson 에 2013년 12월 12일

그러나 컨테이너 fs 이미지 내에 파일을 생성하면 루프백 파일의 공간을 _ 확보 _합니다.
즉, busybox 이미지에서 다음을 수행했습니다.

 cd lib
 cat libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 lib
c.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so
.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 > a_file.bin
/lib # ls -l a_file.bin
-rw-r--r--    1 root     root      47090160 Dec 12 16:41 a_file.bin

이로 인해 데이터 파일이 299M에서 344M으로 증가했습니다. 그러나 a_file.bin을 제거하고 약간 기다렸을 때 299M으로 돌아 왔습니다.

그래서 이것은 devicemapper 버그처럼 보입니다. 즉, Thinp 디바이스에서 기본 디바이스로 폐기 항목을 전달하지만 풀에서 Thinp 디바이스를 제거 할 때 버리지 않습니다.

alexlarsson 에 2013년 12월 12일

이것은 커널 문제인 것 같습니다. BLKDISCARD를 사용하여 문제를 해결하려고했지만 실패했습니다. 자세한 내용은이 버그를 참조하십시오 : https://bugzilla.redhat.com/show_bug.cgi?id=1043527

alexlarsson 에 2013년 12월 16일

https://github.com/alexlarsson/docker/tree/blkdiscard에 해결 방법을 넣었지만 이보다 더 잘할 수 있는지 아직 연구 중입니다.

alexlarsson 에 2013년 12월 17일

이 문제에 대한 업스트림 dm 의견 :
http://device-mapper.org/blog/2013/12/17/thin-provisioning-and-discard-support/

alexlarsson 에 2013년 12월 17일

Docker 0.7.0을 사용하는 CentOS (2.6.32-358.23.2.el6.x86_64)에서도이 문제가 발생합니다. 오래되었지만 문제는 Ubuntu에만 국한되지 않습니다.

blalor 에 2013년 12월 29일

Arch GNU / Linux 3.12.6-1-ARCH, Docker 버전 0.7.2에서 동일한 문제입니다.

skakri 에 2014년 01월 03일

CentOS의 0.7.0에는 여전히 존재합니다.

blalor 에 2014년 01월 07일

우분투 12.04.3 LTS의 0.7.2에는 여전히 존재합니다.

많은 공간이 docker/devicemapper/devicemapper/data 및 metadata 에 있지만 docker/devicemapper/mnt

docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs 에서 컨테이너 파일 시스템을 볼 수 있다는 사실을 배웠습니다.

그러나 내 하드 디스크가 거의 완전히 소모되어 rmdir -r docker 로만 고칠 수 있다는 것은 깔끔하지 않습니다.

nmz787 에 2014년 01월 09일

rspec-system에 대한 도커 지원을 작성하는 동안 비슷한 문제가 있습니다. 내 테스트 VM (도커 호스트)에는 8GB 드라이브가 있으며 이미지를 삭제하지 않고 반복적으로 생성 한 후 드라이브가 가득 찼습니다. 그러나 모든 이미지와 컨테이너를 제거한 후에도 드라이브는 여전히 100 % 가득 차 있습니다. ID-10T 오류라고 생각했지만 VM을 모두 포기하고 파괴했습니다.

logicminds 에 2014년 01월 20일

우분투 13.04의 0.7.5에는 여전히 존재합니다.

mengzechao 에 2014년 01월 21일

이 문제는 최근 병합 된 PR # 3256에 의해 수정되었습니다. 이 수정 사항은 향후 릴리스에 포함될 것입니다.

수정 사항이 마스터에 병합 되었기 때문에 지금이 문제를 종료하겠습니다.

unclejack 에 2014년 01월 21일

참고 : http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=를 사용 하여 커널을 실행할 때까지는 _fully_ 수정되지 않았습니다.

alexlarsson 에 2014년 01월 21일

👍2

공간을 제거하기위한 해결 방법은 무엇입니까? rhel 6.5를 사용하고 있으며 새 커널을 얻는 데 시간이 걸릴 수 있습니다.

내 iPhone에서 보냄

2014 년 1 월 21 일 오전 6:18에 Alexander Larsson [email protected] 은 다음과 같이 썼습니다.
참고 : http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 로 커널을 실행하기 전까지는 완전히 수정되지 않았습니다.
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

logicminds 에 2014년 01월 21일

@logicminds 공간 ATM을 복구하는 아주 쉬운 방법은 없습니다. 기술적으로 루프백 파일을 수동으로 재분할하는 것이 가능해야합니다. 그러나 사용하지 않는 모든 블록을 제로화하거나 희소 영역을 쉽게 감지 할 수 있어야하며, 이는 얇은 장치 제거에서는 수행되지 않습니다.

alexlarsson 에 2014년 01월 22일

@alexlarsson 이것이 OEL 6.5에도 영향을

logicminds 에 2014년 01월 22일

@logicminds 그 커밋이 아직 업스트림 커널에 있는지조차 모르겠습니다. 이 링크는 장치 매퍼 트리에서 가져온 것입니다. 확실히 3.8에는 없습니다.

alexlarsson 에 2014년 01월 22일

공간을 되 찾는 데 사용할 수있는 fstrim과 같은 도구를 만드는 중입니다.

alexlarsson 에 2014년 01월 22일

👍3

@alexlarsson 문제 https://bugzilla.redhat.com/show_bug.cgi?id=1043527 이 공식적으로 "데이터 부족"으로 인해 폐쇄되었습니다. 패치가 커널에 들어 가지 않는다는 의미입니까? 여전히 필요합니까?

kontrafiktion 에 2014년 04월 22일

@vrvolle docker가 사용하는 해결 방법을 만드는 패치는 이미 업스트림입니다. 그래도 그 해결 방법을 불필요하게 만드는 업스트림 작업은없는 것 같습니다.

alexlarsson 에 2014년 04월 22일

기본 2.6.32 커널을 사용하는 centos 6.5의 docker 0.9에서 여전히이 문제가 있습니다.

이전에 device-mapper에 대한이 커밋에 대해 말한 내용을 잘 모르겠습니다. 커널을 3.8로 마이그레이션하면이 버그가 해결되어야하는지 확인할 수 있습니까?

미리 감사드립니다.

nicolas-van 에 2014년 05월 02일

@ nicolas-van 아니요,이 커밋이 필요합니다 : https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

3.14에 있으며 다양한 3.xy 백 포트에있을 수 있습니다.

alexlarsson 에 2014년 05월 05일

이미지를 빌드하고 컨테이너 내에서 실행하기 위해 얼마 전에 docker를 설치했습니다. 그런 다음 얼마 후 Docker 응용 프로그램과 기본 폴더를 포함하여 모든 이미지와 컨테이너를 지 웠습니다.
이제 총 4GB / 24GB의 여유 / 사용 (df -h) 중 du / -sh 명령은 10GB 만보고하므로 다른 10Gb는 고려되지 않습니다. 이는 docker로 생성 된 임시 이미지의 크기보다 작으며이 버그와 관련이있을 수 있습니다. 나는 centos 6.5와 docker 0.9를 사용했습니다.

Jacq 에 2014년 05월 05일

yum을 사용하여 docker를 제거하고 dmsetup을 사용하여 / dev / mapper / docker *에서 devs를 제거하고 rm / var / lib / docker -Rf도 제거했으며 여전히 df 10gb가 사용 된 디스크 보고서는 어디에서도 찾을 수 없습니다.

Jacq 에 2014년 05월 24일

@Jacq 파일 설명자가 열려있는 프로세스에 의해 일부 파일이 여전히

alexlarsson 에 2014년 05월 26일

Linux 3.14.4-1-ARCH 및 docker 0.11.1을 실행하고 모든 이미지와 컨테이너를 제거했습니다.
그리고 파일 / var / lib / docker / devicemapper / devicemapper가 막 붙어서 약 1.5GB를 소비합니다.

여기 mongodb 물건을 조작 한 후의 출력이 있습니다. / var가 그렇게 크지 않기 때문에 파일 크기가 드물게 할당되어야한다고 생각합니다.

~/w/e/video_history ❯❯❯ docker info
Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-254:3-585-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 948.4 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 1.0 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.4-1-ARCH
WARNING: No swap limit support
~/w/e/video_history ❯❯❯ sudo ls -alh /var/lib/docker/devicemapper/devicemapper/data
-rw------- 1 root root 100G Jun  4 14:35 /var/lib/docker/devicemapper/devicemapper/data
~/w/e/video_history ❯❯❯ sudo  du -shc /var/lib/docker/devicemapper/
1.6G    /var/lib/docker/devicemapper/
1.6G    total

Dieterbe 에 2014년 06월 04일

실례합니다. 이제 버그가 수정 되었나요? 젠투에서 만났습니다.

bolasblack 에 2014년 09월 03일

@bolasblack 저는 gentoo를 실행하고이 문제에

x86_64에 대해 3.14.14 인 최신 젠투 소스를 사용하고 있습니다. https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diff를 보았고 그 패치가 내 소스에 적용되었습니다. Docker Docker 버전 1.1.0, 빌드 79812e3이 있습니다.

@alexlarsson 오랜 시간이 지난

arosboro 에 2014년 09월 08일

이것은 여전히 문제입니다! 당분간 AUFS 사용으로 다시 전환 할 것이라고 생각합니다.

daniellockard 에 2014년 09월 17일

@daniellockard AUFS는 비공식적으로 더 이상 사용되지 않는 것 같습니다 : # 783 및 # 4704, 행운을 빕니다.

shabbychef 에 2014년 09월 19일

Yikes ... 그 25GB는 어디로 갔습니까? 아, 하나의 파일에 .... 커널 3.16.2 f20 64b를 실행하고 있습니다.

'해결 방법'에 대한 링크가 깨졌습니다. 무엇입니까? 그리고 내 커널이 그것을 지원합니까 ... Torvalds가 3.14에서 커밋되면 fedora가 3.16에서 볼 수 있다고 생각합니다.

ccjon 에 2014년 09월 23일

analytically 에 2014년 10월 10일

Zolmeister 에 2014년 10월 25일

bleib1dj 에 2014년 11월 04일

+1 Docker 버전 1.3.1, 빌드 4e9bbfa의 Ubuntu Trusty, 3.13.0-36-generic에서 여전히 발생하는 것 같습니다.

Crashthatch 에 2014년 11월 19일

Trusty에도 +1. 3.16을 사용하는 14.10에서 확인할 가치가 있습니까?

4thAce 에 2014년 11월 19일

@SvenDowideit @shykes @vieux @alexlarsson @Zolmeister @creack @crosbymichael @dhrp @ jamtur01 @tianon @erikh @ LK4D4

이것은 우스꽝 스럽기 때문에 최고 커미터를 태깅합니다. 이에 대한 공개 대화와 Docker 팀으로부터이 버그가 주기적으로 중단되어 다시 만들어야하는 컨테이너 또는 시스템으로 이어질 수 있다는 사실을 인정해야합니다. 빌드 봇이 너무 많이 이탈하기 때문에 매주 또는 2 주마다 Docker 호스트를 주기적으로 재 이미징하는 등 미친 데브 옵스 솔루션을 구현해야하는 여러 사람을 이미 알고 있습니다. 나는 거의 1 년 전에이 문제를 소개했으며 내가 말할 수있는 한 거의 확실한 솔루션이 생성되지 않았으며 표면적으로 지원되는 이전 커널은 그렇지 않습니다.

Docker 팀 : 어떤 커널 버전이 영향을 받았는지, 왜, 어떤 패치가 문제를 해결할 것인지를 조사하고 문서화하십시오. 지원하는 커널 버전과 함께 해당 정보를 게시하십시오. 현재 Docker의 소비자는이 문제에 대해 계속해서 매주 또는이 문제에 대한 이메일을 받고 있다는 사실에서 알 수 있듯이이 문제에 대해 계속해서 물어보고 있기 때문입니다. 진지하게, 이것은 파괴적인 문제이며 1.0 이전부터 고통 포인트였습니다.

내가보기에이 문제에 대한 +1을 위해 계속받는 이메일을 중지하는 만족스러운 방식으로이 문제를 해결할 수있는 몇 가지 가능한 옵션이 있습니다.

Device-Mapper가 지원되지 않는 커널에서 사용될 때 사용자에게 알리고 공간을 확보하는 방법에 대한 자세한 지침을 제공하고 가능하면 Docker에서이를 수행하도록 프로세스를 자동으로 설정합니다. 이 알림은이 문제가있는 호스트에 대해 docker CLI를 사용할 때도 표시되어야하므로 docker CLI에서 호스트를 원격으로 관리 할 때 사용자가 일부 호스트가 공간을 올바르게 확보하지 못할 수 있음을 알 수 있습니다.
문제를 해결하십시오 (어떻게 든). 나는 이것이 무엇을 수반하는지 알기에 커널 개발에 대해 충분히 알지 못하지만, 초보 읽기를 기반으로 다음을 제안합니다.

ㅏ. 장치 매퍼는 커널 모듈이므로 dm-docker 와 같이 Docker 소스 트리에 제대로 작동하는 버전을 가져옵니다.

비. 장치 매퍼와 공존 할 수 있도록 dm-docker 를 충분히 변경합니다.

씨. 영향을받는 플랫폼에서 설치시 dm-docker 커널 모듈을 설치하고 기본적으로 dm-docker 합니다.

영향을받는 커널 버전에 대한 경고를 포함하도록 설치 문서 및 docker.com 사이트를 수정하고 패키지에 런타임 검사를 추가하여 올바른 장치 매퍼 작업을 확인하고, 그렇지 않은 경우 사용자에게보고하십시오.

이것은 Docker의 다음 안정 릴리스에 대한 차단 문제가되어야합니다. 계속해서 펀팅을하고 사용자를 곤경에 빠뜨리는 것은 용납 할 수없는 일이기 때문입니다.

AaronFriel 에 2014년 11월 19일

👍32

개인적으로 CoreOS는 Docker를위한 유일한 안정적인 Linux 배포판입니다 (이 문제가 해결 될 때까지).

Docker 팀 :이 문제가 구성 요소로 인한 것이 아니라는 것을 알고 있지만 다른 Linux 배포판에서도 소프트웨어를 사용할 수 있도록 도와주세요. 문서에서 Docker의 잘 알려진 제한 사항으로이 문제를 언급 할 수도 있으므로 다른 사람들이 시간을 낭비하지 않을 것입니다.

감사!
남자 이름

damovsky 에 2014년 11월 19일

+1해야 할 일이 있습니다.

이 문제에 대해 (닫힌) github 문제 목록을 파헤치는 것보다 더 분명한 것이 있다면 좋을 것입니다. 이것이 근본적인 문제임을 실제로 발견하는 데 오랜 시간이 걸렸으며이 문제에 대한 가시성이 좋았을 것입니다.

adamdecaf 에 2014년 11월 19일

우리 업스트림 장치 매퍼 개발자 (나와 Joe Thornber)는이 문제가 여전히 사람들에게 문제라는 사실을 절대적으로 인식하지 못했습니다. 우리는 문제를인지하고 (2013 년 12 월 @alexlarsson에 의해) 즉시 문제를 해결하고 그 당시 _all_ stable 커널에 포함되도록 태그를 지정했습니다. http://git.kernel.org/linus/19fa1a6756ed9e9 ( "dm thin : 이전에 공유 된 블록에 대한 폐기 지원 수정")

Joe Thornber는 @alexlarsson 이 docker go 코드에서 트림 풀을 구현했음을 방금 알게되었습니다. 내가 그에게 지적했을 때 그는 'device-mapper-persistent-data'패키지 (적어도 Fedora, CentOS, RHEL에서)의 일부로 배포 될 적절한 독립형 'thin_trim'도구를 구현했습니다.
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

그래서 ... 모두 말하면, 업스트림 커밋이없는 커널을 실행하는 사용자는 19fa1a6756ed9e9 ( "dm thin : 이전 공유 블록에 대한 폐기 지원 수정")를 더 잘 지원하는 커널을 실행하여 수정해야합니다. 나는 [email protected] 로 쉽게 메모를 채울 수 있습니다. 따라서이 수정 사항이없는 안정적인 커널이 있다면 알려주십시오.

앞으로도 커가 사용중인 씬 풀 장치에 대해 정기적으로 'thin_trim'을 실행하는 docker를 원할 것입니다. 하지만 배포판에서 'thin_trim'이 널리 사용되면 그 다리를 건너 갈 것입니다.

snitm 에 2014년 11월 19일

@shabbychef @daniellockard 아니요, AUF는 더 이상 사용되지 않습니다-먼저 해당 문제 중 하나만 닫히고 계속 읽으면 https://github.com/docker/docker/issues/783#issuecomment -38731137이 읽을만한 가치 :

Our initial plan was to phase out aufs completely because devmapper appeared
 to be the best option in 100% of cases. That turned out not to be true, there 
are tradeoffs depending on your situation and so we are continuing to maintain both.

SvenDowideit 에 2014년 11월 19일

@snitm hack/check_config.sh 에 무언가를 추가하여 커널에이 패치가 없다는 것을 알려줄 수 있습니까?

SvenDowideit 에 2014년 11월 19일

@SvenDowideit 불행히도 문제의 변경 사항은 임의의 커널에서 식별되지 않습니다. 우선 19fa1a6756ed9e9 커밋을 위해 씬 또는 씬 풀 타겟 버전을 충돌시키지 않았습니다. 그러나 그 버전이 모든 안정적인 커널에 걸쳐 다를 수 있습니다 (그래서 '안정적인'커밋 내의 버전 범프가 나쁜 이유입니다. 커밋이 백 포트되는 모든 커널을 수동으로 편집하기 때문입니다).

그러나 씬 풀 대상 버전> = 1.12.0을 가진 사용자는 모두 수정 사항을 갖게됩니다. 따라서 커널> = 3.15. 사용자가 실행중인 도커에는 @alexlarsson 의 docker.git commit 0434a2ce도 포함되어야합니다 ( "devmapper : blkdiscard 옵션 추가 및 원시 장치에서 비활성화").

snitm 에 2014년 11월 19일

참고로 'dmsetup targets'를 실행하면 씬 및 씬 풀 대상 버전이 나열됩니다 (dm-thin-pool 커널 모듈이로드 된 경우).

snitm 에 2014년 11월 19일

관심을 가져 주셔서 감사합니다. 지난주 Re : Invent의 부스 친구들에게 언급했습니다.

dcvii 에 2014년 11월 19일

@snitm 그래서 dmsetup targets 출력을 check-config 출력에 추가해야합니까?

SvenDowideit 에 2014년 11월 19일

헉

씬 프로비저닝 된 장치 매퍼 장치를 생성하고 패치되지 않은 커널에서 여유 공간을 확보하지 못하는 일부 작업을 수행하고이를 기반으로 상태 코드를보고하는 자동화 된 테스트를 생성 할 수 있습니까?

AaronFriel 에 2014년 11월 20일

@SvenDowideit 루프백에서 DM 씬 프로비저닝을 사용하기 시작하기 전에 새로운 문제가되는 커널을 포착하고 싶으십니까?

@AaronFriel 은이 특정 수정 사항에 너무 매달린 범위가 매우 좁아 보입니다. DM 씬 프로비저닝의 엔터프라이즈 급 배포에는이 수정 사항이 적용되었는지 확인하는 것보다 더 많은 것이 있습니다 (불행한 현실). DM 씬 프로비저닝 대상은 커밋 19fa1a675가 업스트림 된 이후 수많은 오류 처리, 성능 및 기능 개선을 보았습니다. 프로덕션에 DM 씬 프로비저닝을 배포 할 때이 모든 것이 중요합니다.

그래서 한 발 뒤로 물러 나면 레이어드 제품이 모든 기본 레이어와 함께 개발되어야한다는 것을 이해하는 회사에서 일하는 것을 즐길 수 있습니다. 그리고 도커와 쌍을 이루는 N 개의 임의 커널에 대한 DM 씬 프로비저닝을 지원하는 데 거의 관심이 없습니다.

그리고 저는 _ 강하게 _ 누구도 루프백 장치와 함께 DM 씬 프로비저닝을 백업 장치로 사용해서는 안된다고 믿습니다. 이것은 "프로덕션에서이게 어떤 모습일까요?"에 대한 적절한 제한이나 걱정없이 도커에 병합 된 완전한 해킹이었습니다.

DM 씬 프로비저닝에 Docker를 적절히 배포하려면 lvm2 기반 씬 프로비저닝 구성이 제공하는 엔터프라이즈 지향 관리 기능이 필요하다는 것을 깨달았습니다. 이를 염두에두고 새로운 하이브리드 관리 솔루션이 작동하도록 꾸준히 노력해 왔습니다. 다음 PR을 참조하십시오.
https://github.com/docker/docker/pull/9006

이 작업은 다음에 따라 다릅니다.
1) lvm2> = 2.02.112
2) DM 씬 풀 대상 버전> = v1.14.0 (Linux 3.19 포함을 위해 linux-next에 준비된 변경 사항)

RHEL7.1에는 이러한 변경 사항이 있습니다. 그리고 RHELAH (Atomic Host)도 마찬가지입니다. DM 씬 프로비저닝에 docker를 올바르게 배포하려는 다른 배포판 / 제품도 마찬가지입니다.

snitm 에 2014년 11월 20일

@snitm 예-저는

그래서 남은 정보의 맥락에서-나는이 끔찍한 놀라움을 유발할 커널 수를 줄이고 싶습니다. :)

SvenDowideit 에 2014년 11월 22일

@SvenDowideit 좋아요, https://github.com/docker/docker/issues/3182#issuecomment -63706507

snitm 에 2014년 11월 22일

@snitm , @AaronFriel
AWS beanstalk, Amazon AMI 에서이 문제처럼 보이는 문제가 있습니다.
(공간 부족)
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64 # 1 SMP 11 월 11 일 화요일 23:07:48 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

$ sudo 도커 버전
클라이언트 버전 : 1.3.2
클라이언트 API 버전 : 1.15
Go 버전 (클라이언트) : go1.3.3
Git 커밋 (클라이언트) : c78088f / 1.3.2
OS / Arch (클라이언트) : linux / amd64
서버 버전 : 1.3.2
서버 API 버전 : 1.15
Go 버전 (서버) : go1.3.3
Git 커밋 (서버) : c78088f / 1.3.2

dbabits 에 2014년 12월 23일

Ubuntu 14.04 및 Docker 1.4.1에서 여전히이 오류가 발생합니다.

reiz 에 2015년 01월 06일

씬 풀 및 씬 버전이> = 1.12.0이라고 믿지 마십시오. 괜찮다는 의미로 CentOS 6.5 VM을 2.6.32-431.29.2.el6.x86_64 커널과 함께 실행하고 있으며 dmsetup 타겟은 다음과 같이보고합니다. thin-pool 및 thin은 모두 v1.12.0입니다. 그러나 나는 40GB 데이터 파일이 스스로 풀리지 않고 붙어 있습니다.

sybrandy 에 2015년 01월 16일

이 버그와 함께 CentOS / RHEL 6.5에서 이것을 실행하는 것은 어떤 의미입니까? 100G 이상의 여유 공간에 문제가 없습니까? 나는 이것이 결국 모든 크기의 디스크를 채운다 고 가정합니까? 아니면 100G로 제한되어 있습니까?

LinuXY 에 2015년 01월 17일

6.5에는 centos에서 사용할 수있는 최신 커널이 없습니다. 나는 간단한 'yum 업데이트'를 6.6으로 권장하고 재부팅하여 2.6.32-504.3.3 커널로 테스트 할 것을 권장합니다.

jperrin 에 2015년 01월 20일

CentOS 6에 대한 최신 커널 및 배포판 업데이트가 제대로 작동하고 공간을 해제하는지 확인합니다.

ripienaar 에 2015년 01월 20일

ripienaar : 사용중인 CentOS 6 및 커널 버전을 명시 적으로 지정할 수 있습니까? 정보를 전달할 때 필요한 정보가 모두 있는지 확인하고 싶습니다.

감사.

sybrandy 에 2015년 01월 20일

@reiz가 위에서 언급했듯이 이것은 최신 Ubuntu 14.04 + 최신

jbiel 에 2015년 01월 20일

기본 OS 항목 :

# uname -a
Linux vagrant-centos65 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/redhat-release
CentOS release 6.6 (Final)

# dmsetup targets
thin-pool        v1.14.0
thin             v1.14.0
mirror           v1.12.0
striped          v1.5.6
linear           v1.1.0
error            v1.2.0

# dmsetup status
docker-8:1-393542-pool: 0 209715200 thin-pool 92343 178/524288 4664/1638400 - rw discard_passdown queue_if_no_space

용법:

# du -h /var/lib/docker/
2.7G    /var/lib/docker/devicemapper/devicemapper
# docker rmi b39b81afc8ca
# du -h /var/lib/docker/
2.5G    /var/lib/docker/devicemapper/devicemapper

해당 커널에 들어가기 전에는 공간을 복구하지 못했습니다.

ripienaar 에 2015년 01월 20일

@jperrin은 이것이 centos 커널 2.6.32-504.3.3을 사용하여 해결

현재 Oracle Enterprise Linux 3.8 UEK 중 하나를 사용하고 있습니다.

lexinator 에 2015년 01월 21일

이 상황에 대한 해결 방법이 있습니까? AWS에서는 인스턴스를 다시 생성하기는 쉽지만 로컬 개발 환경에서는 docker로 인해 device-mapper가 / var 파티션을 90 % 소유하고 있음을 알 수 없습니다. 곧 로그 나 저널을위한 공간도 없을 것입니다.

donrudo 에 2015년 01월 27일

위와 같이

ripienaar 에 2015년 01월 27일

centos에게는 괜찮지 만 일부 개발자는 Fedora와 다른 OpenSuse를 사용하고 있습니다.

donrudo 에 2015년 01월 27일

모든 DM 씬 프로비저닝 변경 사항은 먼저 업스트림으로 전송됩니다. 따라서 Centos 6이 고정되어 있으면 업스트림도 고정됩니다. 다양한 배포판은 수정 사항을 되돌 리거나보다 적극적으로 리베이스해야합니다.

snitm 에 2015년 01월 27일

@ripienaar 다시 묻겠습니다. 수정에 필요한 커널 커밋 (또는 커밋 집합)을 알고 있습니까?

lexinator 에 2015년 01월 27일

@lexinator 아니에요

ripienaar 에 2015년 01월 27일

Ubuntu 14.04 Trusty 및 커널 3.13.0-36-generic에서이 문제가 나타납니다. 가능한 솔루션은 AWS EBS 스토리지를 디렉터리에 연결하여 무기한 확장 할 수 있도록하는 것입니다.

TylerMills 에 2015년 01월 27일

여러분,이 문제는 정말 아파요. CoreOS는 현재 ext4로 이동하고 있으며 곧 CoreOS에서도이 모든 문제가 발생할 것입니다.

이 문제가 1 년 이상 해결되지 않은 상태에서 사람들은 어떻게 도커를 사용할 수 있습니까 (dev 또는 prod에서)? 모두 끝없는 디스크를 가지고 있습니까?

sirocode 에 2015년 01월 28일

devmapper가 아닌 오버레이를 위해 ext4로 이동하고 있다고 생각합니다. 하지만 그건
길거리의 단어 만 ...

2015 년 1 월 28 일 수요일에 Sergey [email protected] 은 다음과 같이 썼습니다.

여러분,이 문제는 정말 아파요. CoreOS는 현재 ext4로 이동하고 있습니다.
CoreOS에서도이 모든 문제가 발생합니다.
이 문제가 해결되지 않은 동안 사람들이 docker (dev 또는 prod)를 사용할 수있는 방법
1 년 이상? 모두 끝없는 디스크를 가지고 있습니까?
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/3182#issuecomment -71800923.

jessfraz 에 2015년 01월 28일

혼란 스럽습니다. Google 인스턴스의 디스크 공간은 10G에 불과하지만 / var / lib / docker / devicemapper / devicemapper / data의 크기는 100G로 표시됩니다. 모든 컨테이너와 이미지를 삭제 한 후에도 공간을 확보 할 수 없습니다.

manjugit 에 2015년 02월 08일

스파 스 파일입니다. 사용 ls -sh 대신 ls -l , 또는 교대 du -h

jperrin 에 2015년 02월 09일

우분투 13.04에서보고 할 수 있습니다 (아마도 놀랄 일이 아닙니다).

devicemapper의 증가를 예상 할 수있는 충분한 디스크 공간을 프로비저닝하는 유일한 해결 방법이 현재 있습니까?

andrewcstewart 에 2015년 02월 11일

이 전체 스레드는 아주 우스꽝 스럽습니다. 한 명의 데비안 사용자가 불평을합니다. 문제가 발생하면 적절하게 유지 관리되는 배포판으로 전환하거나 배포판 관리자와 협력하여 문제를 해결하도록해야합니다. 이러한 배포판은 수정 또는 개선 사항을 따라 가지 못합니다. 수정이 이미 분명히 업스트림 (CentOS 또는 RHEL 참조) 인 경우 distro $ foo에서이 문제를 수정 해 달라는 향후의 모든 간청을 무시할 것입니다. 문제의 손상된 배포판에 대한 버그를 열고이 문제를 참조하세요.

snitm 에 2015년 02월 11일

Docker가 다음 플랫폼에서 지원을 유지하는 것은 그렇게 어리석은 일이 아닙니다.

Docker is supported on the following versions of Ubuntu:

Ubuntu Trusty 14.04 (LTS) (64-bit)
Ubuntu Precise 12.04 (LTS) (64-bit)
Ubuntu Raring 13.04 and Saucy 13.10 (64 bit)

이 문제가 분명히 널리 퍼 졌을 때 어떻게 14.04에 대한 총괄 지원 전화를받을 수 있습니까? Docker는 특정 배포판에서 특정 커널에 대한 포괄적 인 지원을 분명히 삭제해야합니다.

CentOS를 사용하고 있으며 커널 업그레이드로 인해 장치 매퍼 사용 문제가 개선 된 것 같습니다.

어쨌든 @snitm 작업에 감사드립니다.

dekz 에 2015년 02월 14일

Ubuntu에서이 문제가있는 경우 이전 도커 이미지 / 컨테이너를 적절하게 정리하고 있는지 확인하십시오. 내가 생각할 때 내 정리 스크립트가 실행되고 있지 않다는 것을 알게되었고, 이것이 너무 많은 공간을 사용하는 이유입니다.

```#! / bin / bash

모든 컨테이너 삭제

도커 rm $ (도커 ps -a -q)

모든 이미지 삭제

도커 rmi $ (도커 이미지 -q)
```

TylerMills 에 2015년 02월 18일

@TylerMills 는 docker rm 가 컨테이너에 의해 생성 된 볼륨을 제거하지 _ 않습니다 _. 컨테이너에서 볼륨을 사용하는 경우 docker rm -v 를 사용하여 docker에서 볼륨도 제거하도록해야합니다.

thaJeztah 에 2015년 02월 18일

@snitm 우분투 14.04를 사용하여 이것도 조금 얻었습니다. 특히 Docker의 잘못이 아닐 수도 있지만 전체 경험을 제대로 반영하지 못하기 때문에이를 수정하는 데 큰 관심을 가져야합니다.

bkeroackdsc 에 2015년 02월 28일

또한 나는이 문제에 부딪 혔고 이것이 내가 그것을 고치기 위해 한 일입니다.

하지만 제 경우에는 / var가 100 % 사용에 도달했을 때 마운트 된 장치로 인해 호스트가 커널 패닉 상태가되는 것을 막는 유일한 방법은 도커 프로세스를 직접 종료하는 것입니다 (즉, 도커 명령을 실행하면 패닉이 발생 함).

그런 다음이 명령을 사용하여 devicemapper 마운트를 사용하여 모든 프로세스를 수동으로 종료합니다.

grep docker /proc/*/mounts | awk -F/ '{ print $3 }' | xargs kill -9

그런 다음 다음을 사용하여 devicemapper 마운트를 해제 할 수있었습니다.

for i in /dev/mapper/docker-*; do umount $i; dmsetup remove $i; done

이 단계는 내가 공간을 되찾거나 파일을 삭제할 수있는 모든 파일 설명자를 릴리스했습니다 ..

제 경우에는 / var / lib / docker 디렉토리를 더 많은 공간이있는 마운트로 이동하고 -g 인수를 사용하여 다른 홈 디렉토리를 사용하도록 docker 데몬을 구성하는 것이 더 합리적이었습니다.

Adam Miller를 통해 Alexander Larsson 에게 감사드립니다.

JohnMorales 에 2015년 03월 02일

@dekz 주석에 이어 설치 가이드가 사용자에게이 수정이없는 커널 버전이 여기에서 수행 된대로 허용된다는 것을 지시하지 않았다면 아마도 좋은 생각 일 것입니다 : https://docs.docker.com/installation/ubuntulinux/

reub 에 2015년 04월 08일

감사합니다 @JohnMorales. Docker에서 이에 대한 약간의 경고가 있으면 좋은 생각이 될 것입니다.

xer0x 에 2015년 04월 14일

ramantalkin 에 2015년 04월 19일

cpoonolly 에 2015년 04월 29일

우리는 최근 Ubuntu 14.04.2 LTS (3.16.0-30-generic)를 실행하는이 문제를 해결했으며 여전히 솔루션을 찾기 위해 노력하고 있습니다. 아마도 커널 수정이있는 CentOS 6.6으로 전환하거나 더 큰 디스크가있는 볼륨을 마운트하는 것이 유일한 해결책 인 것 같습니다.

Ubuntu를 실행하는 사람이 허용 가능한 해결 방법을 찾았습니까?

동의합니다. Docker는이 문제를 해결해야합니다. 문서와 경고 메시지가 필요한 심각한 버그이므로 더 많은 사람들이 순진하게 같은 함정에 빠지지 않습니다.

natea 에 2015년 05월 07일

@natea에 동의합니다
나는 redhat 6.5와 동일한 문제에 직면하고 있으며 docker가 생산 준비가되어 있고 우리가 대안을 찾기 시작하면 큰 물음표를 던지고 있습니다.
문제를 해결하기 위해 수동 해결 방법을 얻는 것도 괜찮지 만 지금 당장은 실행 가능한 해결 방법을 알지 못합니다.

sagiegurari 에 2015년 05월 07일

@sagiegurarie 는 6.5 (및 관련 커널)의 다양한 문제로 인해 CentOS에 대한 요구 사항을 6.6으로

thaJeztah 에 2015년 05월 07일

그래서 문제 # 11643 답변은 관련이 없습니까? 그것은 우리가 redhat 6.5를 사용할 수 없다는 것을 의미합니까?

sagiegurari 에 2015년 05월 07일

@natea @sagiegurari 무엇이 우리를 위해 작동하는 @TylerMills에 의해 제안 설명서 "수정"입니다

# Delete all containers
docker rm $(docker ps -a -q)
# Delete all images
docker rmi $(docker images -q)

물론 단점은 모든 이미지를 다시 가져와 컨테이너를 다시 실행해야한다는 것입니다.

bkeroackdsc 에 2015년 05월 07일

@bkeroackdsc 이전에도 모든 컨테이너와 이미지를 삭제했는데 해결되지 하지만 다시 한번 시도해 보겠습니다.

sagiegurari 에 2015년 05월 07일

안녕하세요! 이 문제가 ubuntu-15.04에 여전히 존재하는지 알고 싶습니다. 현재 linux-3.19 커널에 있습니다. 감사합니다.

dreamcat4 에 2015년 05월 07일

ubuntu-15.05에 해당 커널을 사용하는 경우 오버레이를 사용하지 않는 이유는 다음과 같습니다.
devicemapper보다 낫다

2015 년 5 월 7 일 목요일 오전 11:26에 Dreamcat4 [email protected] 은 다음과 같이 썼습니다.

안녕하세요! 이 문제가 ubuntu-15.04에 여전히 존재하는지 알고 싶습니다.
현재 linux-3.19 커널에 있습니다. 감사합니다.
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/3182#issuecomment -99968299.

jessfraz 에 2015년 05월 07일

@jfrazelle 아 맞다. 그것을 무엇처럼? 오버레이를 사용하십니까? 3.19 커널에서 오버레이 지원이 아직 실험적이라는 가정하에 (지금까지) 진행했습니다.

dreamcat4 에 2015년 05월 07일

예, 오버레이를 사용합니다. :) 우리는 1.7 잃어버린 목록에서 위로 이동하기를 바랍니다.
그것을 사용하고 그것을 사랑하십시오

2015 년 5 월 7 일 목요일 Dreamcat4 [email protected] 은 다음과 같이 썼습니다.

@jfrazelle https://github.com/jfrazelle 아 맞다. 그것을 무엇처럼? 하다
오버레이를 사용하십니까? 나는 (지금까지) 가정하에
오버레이 지원은 3.19 커널에서 아직 실험적이었습니다.
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/3182#issuecomment -99982543.

jessfraz 에 2015년 05월 07일

@sagiegurari 왜 6.5를 고수합니까? 이름이있는 뉴스 가치가있는 CVE를 포함하여 6.6으로 이동하지 않음으로써 누락 된 업데이트 및 수정 사항이 많이 있습니다.

jperrin 에 2015년 05월 07일

내 결정이 아니기 때문에
어쨌든 나는 모든 팀과 함께 redhat 7이 프로덕션에 적합한 지 확인하려고합니다.

sagiegurari 에 2015년 05월 12일

CentOS7 (3.10.0-123.el7.x86_64)에서 여전히 문제인 것 같습니다. 새 CentOS 상자를 설정하고 docker v1.6.0을 설치했습니다. devicemapper 데이터 파일은 sudo docker rmi 이후에 크기를 줄이지 않습니다. 나는 그것을 시험해보기 위해 CentOS6.6 상자를 찾고 있습니다.

alexDrinkwater 에 2015년 05월 20일

Ubuntu 14.04의 v1.6.0은 긍정적 인 효과를 보였습니다 (v1.5.0 이상)

Zolmeister 에 2015년 05월 21일

redhat 7에서도 말할 수있는 centos 7에서도 잘 작동하는 것 같습니다.
그러나 redhat 6.5는 그렇지 않으며 문서에 언급하는 것이 좋습니다.

sagiegurari 에 2015년 06월 03일

이것은 최신 업스트림 도커에서 작동해야합니다. 그리고 @sagiegurari의 마지막 코멘트는

이 경우이 버그를 종료해야합니다.

그렇다면이 문제는 최신 Docker에서 여전히 발생합니까? 그렇지 않은 경우 닫습니다.

rhvgoyal 에 2015년 06월 08일

음 .... 더 많은 테스트를 실행하면 불확실한 결과가 나오는 것 같습니다.
훨씬 낫다고 말할 수 있지만 여전히 누출이 발생할 수 있습니다.
확인을 위해 더 많은 수표를 실행할 것입니다.

sagiegurari 에 2015년 06월 08일

헉헉

현재 직면하고있는 문제와 환경에 대해 좀 더 자세히 설명해 주시겠습니까? 문제의 제목은 이미지 / 컨테이너 삭제시 공간이 회수되지 않으며 최신 업스트림 도커에는 그러한 문제가 없어야한다고 말합니다.

업스트림 도커를 가져 와서 동적 바이너리를 만들고, 새로운 씬 풀 (신선한 / var / lib / docker /) 디렉터리를 만들고, 이미지를 가져 와서 삭제하고 도커 정보를 살펴보고 공간이 확보되었는지 확인하거나 아니.

rhvgoyal 에 2015년 06월 09일

더 정확한 정보를 제공하기 위해 다음 주에 더 많은 테스트를 실행할 것입니다.

많은 이미지를 생성하고 제거하는 (빌드 자체 중) + docker 레지스트리 2.0 (항상 'latest'태그로 다른 이미지를 푸시) 실행 + 몇 개의 컨테이너를 실행하는 빌드 머신에서 볼 수 있음을 인정합니다. 모든 것이 잘 작동하는지 초기 테스트를 수행합니다 (테스트는 실제로 해당 머신에서 실행되지 않아야하지만 초기 단계이므로 많은 컨테이너를 생성 / 중지 / rm).

우리의 이미지는 정말 크고 때로는 2GB 이상의 가상 크기가 표시되므로 문제가 있으면 일반적으로 약 400mg의 일반적인 이미지보다 빠르게 나타납니다.

어쨌든 다음 주에 동작을 확인하고 자세한 내용을 제공하기 위해 몇 가지 테스트를 실행하려고합니다.

sagiegurari 에 2015년 06월 10일

Docker 버전 1.6.0을 사용하여 Linux 커널 3.14.35-28.38.amzn1.x86_64에서 빌드 4749651 / 1.6.0

이미지를 제거하면 Docker가 요구하는 디스크 공간이 줄어 듭니다.

stanislavb 에 2015년 06월 10일

뿡뿡

이 문제를 닫을 수 있습니까? 최신 도커에서는 oop 파일에서 이미지 / 컨테이너 공간을 회수하는 문제가 있다고 생각하지 않습니다. 특정 문제가 발생하면 특정 세부 사항으로 새로운 문제를 열 수 있습니다.

rhvgoyal 에 2015년 06월 12일

@rhvgoyal 너무 많은 사람들이 너무 많은 플랫폼 / 버전에 대해 불평 한 후

sagiegurari 에 2015년 06월 12일

헉헉

나는 이슈를 공개함으로써 우리가 무엇을 얻는 지 모르겠습니다. 나는 그것이 상류에 고정되어 있다는 것을 알고 있습니다. 열려있는 문제가 너무 많습니다. 사람들은 관찰을 기록하기 위해 대시 보드로 사용하고 있습니다.

실제로 재현 가능한 문제가있는 경우에만 문제를 공개하는 것이 합리적이라고 생각합니다. 그렇지 않으면이 문제 목록이 계속 늘어나고 어떤 문제에 집중해야할지 파악하기가 어렵습니다.

일단이 문제에 더 많은 데이터를 추가하는 것을 막을 수있는 사람은 없습니다.

rhvgoyal 에 2015년 06월 12일

@rhvgoyal 최신 업스트림에서 어떤 태그를 언급하고 있습니까?

alexDrinkwater 에 2015년 06월 12일

@rhvgoyal 최신 커밋을 말합니다. 최신 git 트리를 복제하고 테스트합니다. 정말 중요합니까?

rhvgoyal 에 2015년 06월 12일

이전 Docker 릴리스와 이전 커널에서 너무 많은 문제가보고됩니다. 첫 번째 단계는 최신 도커와 비교적 새로운 커널에서 동일한 문제가 보이는지 확인하는 것입니다. 그것은 그것이 여전히 문제인지 또는 이전 버전에서 수정되지 않은 것인지 우리에게 아이디어를 제공합니다.

rhvgoyal 에 2015년 06월 12일

누군가가 돌아와 미래에 그것을 읽으면 그렇습니다. 어떤 버전으로 수정되었는지 알고 싶었습니다.

alexDrinkwater 에 2015년 06월 12일

루프백 장치의 경우 폐기를 발행합니다. 실제로 오래 전에 이루어졌습니다. 1.6에 있어야한다고 생각합니다.

rhvgoyal 에 2015년 06월 12일

@stanislavb 는 1.6으로 테스트했으며 그에게

rhvgoyal 에 2015년 06월 12일

이 문제의 첫 번째 의견을 참조하면 centos7에서 v1.6.0으로 시도했지만 여전히 문제가 있음을 알 수 있습니다.

alexDrinkwater 에 2015년 06월 12일

안녕하세요.

좋습니다. 재현 할 수 있습니까? 어떤 종류의 씬 풀을 사용 했습니까 (루프 장치 위에?). Docker를 다시 시작 했습니까? 아니면 Docker를 처음 시작할 때 발생합니까?

어떤 경우에는 docker가 루프 장치를 사용하고 나서 docker가 다시 시작될 수 있으며 일부 장치가 어딘가에서 사용 중이 어서 풀이 종료되지 않았을 수 있습니다. Docker를 다시 시작할 때
이미 거기에있는 풀을 찾고 루프백 장치가 사용되고 있다는 것을 알지 못하며 폐기를 발행하지 않습니다. 당신이 그 상황에 뛰어들 었는지 궁금 해요?

rhvgoyal 에 2015년 06월 12일

CentOS 7

Docker 버전 1.6.2.el7, 빌드 c3ca5bb / 1.6.2

이미지 정리 전

[root<strong i="8">@b2</strong> ~]# docker info
Containers: 1
Images: 320
Storage Driver: devicemapper
 Pool Name: docker-8:2-1076248517-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 10.74 GB
 Data Space Total: 107.4 GB
 Data Space Available: 96.63 GB
 Metadata Space Used: 22.8 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.125 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.63-11.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 32
Total Memory: 31.52 GiB

[root<strong i="11">@b2</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      483443064 13100584 470342480   3% /

일부 도커 rmi 후

[root<strong i="15">@b2</strong> ~]# docker info
Containers: 1
Images: 143
Storage Driver: devicemapper
 Pool Name: docker-8:2-1076248517-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 7.215 GB
 Data Space Total: 107.4 GB
 Data Space Available: 100.2 GB
 Metadata Space Used: 14.68 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.133 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.63-11.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 32
Total Memory: 31.52 GiB

[root<strong i="18">@b2</strong> ~]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda2      483443064 9665924 473777140   2% /

stanislavb 에 2015년 06월 12일

안녕하세요.

좋아, 방금 centos7 이미지를 부팅하고 docker 1.6을 사용해 보았지만 문제가 보이지 않습니다. 단계는 다음과 같습니다.

[ root @ centos7-generic ~] # 도커 버전
클라이언트 버전 : 1.6.0
클라이언트 API 버전 : 1.18
Go 버전 (클라이언트) : go1.4.2
Git 커밋 (클라이언트) : 8aae715 / 1.6.0
OS / Arch (클라이언트) : linux / amd64
서버 버전 : 1.6.0
서버 API 버전 : 1.18
Go 버전 (서버) : go1.4.2
Git 커밋 (서버) : 8aae715 / 1.6.0
OS / Arch (서버) : linux / amd64

이미 하나의 이미지를 가져 왔습니다.

[ root @ centos7-generic ~] # 도커 이미지
저장소 태그 이미지 ID가 생성 된 가상 크기
docker.io/fedora 최신 ded7cd95e059 2 주 전 186.5 MB

다음은 도커 정보의 출력입니다.

root @ centos7-generic ~] # 도커 정보
컨테이너 : 0
이미지 : 2
스토리지 드라이버 : devicemapper
풀 이름 : docker-253 : 1-50331788-pool
풀 블록 크기 : 65.54 kB
백업 파일 시스템 : xfs
데이터 파일 : / dev / loop0
메타 데이터 파일 : / dev / loop1
사용 된 데이터 공간 : 525.5MB
총 데이터 공간 : 107.4GB
사용 가능한 데이터 공간 : 20GB
사용 된 메타 데이터 공간 : 892.9kB
총 메타 데이터 공간 : 2.147GB
사용 가능한 메타 데이터 공간 : 2.147GB
Udev 동기화 지원 : true
데이터 루프 파일 : / var / lib / docker / devicemapper / devicemapper / data
메타 데이터 루프 파일 : / var / lib / docker / devicemapper / devicemapper / metadata
라이브러리 버전 : 1.02.93-RHEL7 (2015-01-28)
실행 드라이버 : native-0.2
커널 버전 : 3.10.0-229.el7.x86_64
운영 체제 : CentOS Linux 7 (코어)
CPU : 2

[ root @ centos7-generic ~] # docker rmi fedora
태그 없음 : 페도라 : 최신
삭제 : ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
삭제 : 48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ root @ centos7-generic ~] # 도커 정보
컨테이너 : 0
이미지 : 0
스토리지 드라이버 : devicemapper
풀 이름 : docker-253 : 1-50331788-pool
풀 블록 크기 : 65.54 kB
백업 파일 시스템 : xfs
데이터 파일 : / dev / loop0
메타 데이터 파일 : / dev / loop1
사용 된 데이터 공간 : 307.2MB
총 데이터 공간 : 107.4GB
사용 가능한 데이터 공간 : 20.22GB
사용 된 메타 데이터 공간 : 733.2kB
총 메타 데이터 공간 : 2.147GB
사용 가능한 메타 데이터 공간 : 2.147GB
Udev 동기화 지원 : true
데이터 루프 파일 : / var / lib / docker / devicemapper / devicemapper / data
메타 데이터 루프 파일 : / var / lib / docker / devicemapper / devicemapper / metadata
라이브러리 버전 : 1.02.93-RHEL7 (2015-01-28)
실행 드라이버 : native-0.2
커널 버전 : 3.10.0-229.el7.x86_64
운영 체제 : CentOS Linux 7 (코어)
CPU : 2

알림 데이터 사용량이 525MB에서 307MB로 감소했습니다. 그래서 이미지를 삭제하면 공간이 다시 확보되었습니다.

rhvgoyal 에 2015년 06월 12일

좋아, 작업 전후에 루프 파일의 크기를 붙여 넣는 것을 잊었습니다. 여기있어.

이미지를 당기기 전에.
$ cd / var / lib / docker / devicemapper / devicemapper
$ du -h 데이터
293M 데이터
이미지 풀 후
[ root @ centos7-generic devicemapper ] # du -h 데이터
499M 데이터
이미지 삭제 후
[ root @ centos7-generic devicemapper ] # du -h 데이터
293M 데이터

그래서 내 루프 파일은 실제로 이미지 삭제 후 축소되었습니다. 나는 그것이 당신이 불평하는 것이라고 생각합니다.

rhvgoyal 에 2015년 06월 12일

뿡뿡

루프 파일을 사용하고 있습니까? Docker 정보에는 표시되지 않습니다. 도 커가 시작되었을 때 풀이 이미 있던 것과 동일한 문제가 발생하고 있다고 생각합니다.

루프 백업 파일 (/ var / lib / docker / devicemapper / devicemapper / data)의 크기를 확인하고 이미지 삭제 후 파일이 축소되는지 확인할 수 있습니다. (du -h).

rhvgoyal 에 2015년 06월 12일

뿡 빵뀨
CentOS 7, Docker 버전 1.6.2.el7, 빌드 c3ca5bb / 1.6.2

[root<strong i="7">@b2</strong> ~]# du /var/lib/docker/devicemapper/devicemapper/data
7041272 /var/lib/docker/devicemapper/devicemapper/data
[root<strong i="8">@b2</strong> ~]# docker rmi $(docker images -q)
...
[root<strong i="9">@b2</strong> ~]# du /var/lib/docker/devicemapper/devicemapper/data
5617292 /var/lib/docker/devicemapper/devicemapper/data

stanislavb 에 2015년 06월 12일

뿡뿡

좋습니다. 루프 장치 크기가 실제로 줄어들고 있습니다.

또한 코드에서 확인했습니다. 다시 시작할 때 docker가 이미 씬 풀을 찾은 경우에도 폐기를 발행합니다.

    // By default, don't do blk discard hack on raw devices, its rarely useful and is expensive
    if !foundBlkDiscard && (devices.dataDevice != "" || devices.thinPoolDevice != "") {
            devices.doBlkDiscard = false
    }

위의 코드에 따라 사용자가 데이터 블록 장치 또는 씬 풀을 전달한 경우에만 폐기가 비활성화됩니다. 우리가 어느 쪽도 통과하지 않았다는 점을 감안할 때, 폐기는 여전히 켜져 있습니다. 그것이 당신을 위해 일하는 이유입니다.

@alexDrinkwater 이제 1.6에서 수정 된 두 개의 데이터 포인트가 있습니다. 이 문제를 해결하는 데 여전히 우려 사항이 있습니까?

rhvgoyal 에 2015년 06월 12일

CentOS 6.6

Docker 버전 1.5.0, 빌드 a8a31ef / 1.5.0

이미지 정리 전

[root<strong i="8">@b1</strong> ~]# docker info
Containers: 2
Images: 2996
Storage Driver: devicemapper
 Pool Name: docker-8:2-21890120-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 43.24 GB
 Data Space Total: 107.4 GB
 Metadata Space Used: 117.1 MB
 Metadata Space Total: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 2.6.32-504.16.2.el6.x86_64
Operating System: <unknown>
CPUs: 32
Total Memory: 31.33 GiB

[root<strong i="11">@b1</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      475957304 53995488 397777856  12% /

남은 1929 개의 이미지에서 데이터 파일 크기 확인

[root<strong i="15">@b1</strong> ~]# du -h /var/lib/docker/devicemapper/devicemapper/data
30G /var/lib/docker/devicemapper/devicemapper/data

일부 도커 rmi 후

[root<strong i="19">@b1</strong> ~]# docker info
Containers: 2
Images: 497
Storage Driver: devicemapper
 Pool Name: docker-8:2-21890120-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 13.39 GB
 Data Space Total: 107.4 GB
 Metadata Space Used: 27.87 MB
 Metadata Space Total: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 2.6.32-504.16.2.el6.x86_64
Operating System: <unknown>
CPUs: 32
Total Memory: 31.33 GiB

[root<strong i="22">@b1</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      475957304 25606060 426167284   6% /
[root<strong i="23">@b1</strong> ~]# du -h /var/lib/docker/devicemapper/devicemapper/data
13G /var/lib/docker/devicemapper/devicemapper/data

stanislavb 에 2015년 06월 12일

좋아, 1.5에서도 작동합니다.

rhvgoyal 에 2015년 06월 12일

나는 이것을 새 컴퓨터에서 테스트했습니다.

Docker 버전 1.6.0, 빌드 8aae715 / 1.6.0

당기기 전 :

/dev/mapper/os-var                             3.9G  750M  2.9G  21% /var

Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 307.2 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.308 GB
 Metadata Space Used: 733.2 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

풀 후 :

/dev/mapper/os-var                             3.9G  815M  2.9G  23% /var

Containers: 0
Images: 22
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 639.9 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.24 GB
 Metadata Space Used: 1.438 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.146 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

이미지 제거 :

sudo docker rmi 617ef0e7677f
Untagged: docker.io/ghost:latest
Deleted: 617ef0e7677fbff322b8f3af29b9795314a333876d66b49e1ddede15229dccea
Deleted: e68d1ee297168a0b3c3e21ff7a9ab14f7df8edf4525e008fcaf3abc83c731387
Deleted: 4eee85e0d29b6836d3d46ff3b84b0292626df5c8428da0aeeb916d33b6fb7642
Deleted: d0e1169bd5617096df1776902e191f23c07ac0fb5b365c5664fd3d4a554e4c8e
Deleted: e983dda26a2392947fffa4cc37b36251b84bbc74c95ce9c353b80a9c8e63d70f
Deleted: 64b0f4c09fde536675106331c31636f8478ed0cf5c2c7aa274d464216e470b3f
Deleted: c0313e19f503a4770c00250049419a014972ba8f3458524d61b377b8fd289ef0
Deleted: ff1093062f402021a7574b3c40692d2c6dc7aec07d66e17caa6c35df19bad091
Deleted: 37b39063e0c0f3c1a8c90d304ad7ba6b47e14242ff60f6f5d091b280258e0ff3
Deleted: 6e878a0c2422a5496d6bfc5eaf1facbc48f66a8e437fdd7db18d8944b20f7072
Deleted: a10b93053713fb726beaea993bad52b39ca92c5ce6b646dbc7d9cd96016ee9bc
Deleted: 1324d506b72f2a602a8f55c5224708e8ff02dec86b5fe46462a1d73aafb32075
Deleted: 70014f2a472b03d0cfde21d99c601db25f62de1d6c8497cadd6e05743c09d5a1
Deleted: f81216b6a47e2f51c80ff56044a5120d4b8cb76e9ea5990ba08ed073e97fd429
Deleted: 286e04b15dcfe587da0d8b6b359d6ae74c3ef299b868183859508304153ceaca
Deleted: 1dbb5edeebca3ae23a32fcf600015df645a788747553287548ce67126b206ab7
Deleted: 8807133d30b36044c670a06b087b6b61082b660a61fef651f0871283c5505bff
Deleted: 4c0283973ca2335a9ae82168956e4add2e6f2f13fd31e16473d695912e34d974
Deleted: 95d6d696e46933c9d063b5d6328b1a92b988462f1277d74d42bbbdd568efc220
Deleted: 80565b90e8eb693f03cea0411aadb45f21f2bcfe39f6b0fda8cf351eaee1f81b
Deleted: df2a0347c9d081fa05ecb83669dcae5830c67b0676a6d6358218e55d8a45969c
Deleted: 39bb80489af75406073b5364c9c326134015140e1f7976a370a8bd446889e6f8

삭제 후 :

/dev/mapper/os-var                             3.9G  814M  2.9G  23% /var

Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 307.2 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.24 GB
 Metadata Space Used: 733.2 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

alexDrinkwater 에 2015년 06월 12일

내 컴퓨터 또는 버전 등에 대한 자세한 내용이 있으면 알려주십시오.

alexDrinkwater 에 2015년 06월 12일

안녕하세요.

/ var에 별도의 장치를 마운트하는 것 같습니다. 해당 장치의 파일 시스템은 무엇이며 마운트 옵션은 무엇입니까?

rhvgoyal 에 2015년 06월 12일

또한 나에게 다음을 줄 수 있습니다.

dmsetup 테이블
dmsetup 상태
고양이 / etc / sysconfig / docker-storage

rhvgoyal 에 2015년 06월 12일

xfs 파일 시스템을 사용하여 루트 자체에 / var를 유지하는 더 간단한 경우를 시도해 볼 수 있습니다. 문제의 범위를 좁히려 고합니다.

rhvgoyal 에 2015년 06월 12일

안녕하세요.

루프백 백업 파일이 xfs 대신 ext4에 있고 여전히 작동하도록 / var / lib / docker에 ext4 파티션이있는 다른 디스크를 마운트했습니다.

/ var / lib / docker 유형 ext4의 / dev / vdb1 (rw, relatime, seclabel, data = order)

설정의 특별한 점이 무엇인지 확실하지 않습니다.

rhvgoyal 에 2015년 06월 12일

구체적으로 말하자면

당기기 전에
/ dev / vdb1 9.8G 338M 8.9G 4 % / var / lib / docker
이미지 풀 후
/ dev / vdb1 9.8G 544M 8.7G 6 % / var / lib / docker
이미지 삭제 후
/ dev / vdb1 9.8G 338M 8.9G 4 % / var / lib / docker

rhvgoyal 에 2015년 06월 12일

안녕하세요.

설정과 내 설정의 다른 주요 차이점은 커널 버전입니다. "3.10.0-229.el7.x86_64"를 사용하고있는 반면 "3.10.0-123.el7.x86_64"를 사용하는 것 같습니다. 커널을 업그레이드하고 사용해 볼 수 있습니까?

rhvgoyal 에 2015년 06월 12일

@rhvgoyal의 도움에 감사드립니다. 오늘은 커널을 업데이트 할 수 없습니다. 하지만 요청한 설정은 다음과 같습니다.

/dev/mapper/os-var /var ext3 rw,relatime,data=ordered 0 0

vgdocker-lvdocker: 0 62906368 linear 8:17 2048
os-tmp: 0 8388608 linear 8:2 5244928
os-var: 0 8388608 linear 8:2 13633536
os-swap: 0 5242880 linear 8:2 2048
os-root: 0 8388608 linear 8:2 22022144
docker-253:3-247472-pool: 0 209715200 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroing

vgdocker-lvdocker: 0 62906368 linear 
os-tmp: 0 8388608 linear 
os-var: 0 8388608 linear 
os-swap: 0 5242880 linear 
os-root: 0 8388608 linear 
docker-253:3-247472-pool: 0 209715200 thin-pool 79 179/524288 4688/1638400 - rw discard_passdown queue_if_no_space

DOCKER_STORAGE_OPTIONS=

구성된 사용자 지정 저장소 옵션이 없습니다.

alexDrinkwater 에 2015년 06월 12일

그것을 발견. 나는 그것이 ext3 파일 시스템과 관련이 있다고 생각합니다. 나도 문제를 볼 수 있습니다. ext4 또는 xfs와 같은 다른 파일 시스템을 시도하면 문제가 발생하지 않습니다.

/ var / lib / docker 유형 ext3의 / dev / vdb1 (rw, relatime, seclabel, data = order)

이미지를 가져 오기 전
[ root @ centos7-generic-2 devicemapper ] # du -h 데이터
293M 데이터
이미지를 가져온 후
[ root @ centos7-generic-2 devicemapper ] # du -h 데이터
501M 데이터
이미지 제거 후
[ root @ centos7-generic-2 devicemapper ] # du -h 데이터
501M 데이터

따라서 어떤 이유로 루프백 파일이 ext3 파일 시스템에 있으면 작동하지 않습니다. ext3이 충분히 오래되어 루프 폐기가 작동하지 않을 수 있습니다.

rhvgoyal 에 2015년 06월 12일

감사합니다. 파일 시스템이 ext3 인 것을 보자 마자 그럴 수 있다고 생각했습니다. ext3에서 문제를 재현 할 수 있다면이 문제를 종결이라고 할 수 있습니다. 다른 사람들에게 좋은 참고 자료가 될 것입니다.

alexDrinkwater 에 2015년 06월 12일

참고로 내 작업 예제는 xfs 파일 시스템의 Docker 1.6.2와 ext4의 Docker 1.6.0 및 1.5.0입니다.

stanislavb 에 2015년 06월 13일

뿡뿡

닫아도 될까요? 공간 회수는 xfs 및 ext4에서 잘 작동합니다. ext3는 지원하기에 너무 오래된 것 같습니다.

rhvgoyal 에 2015년 06월 16일

@rhvgoyal @vbatts IIRC, 기본 파일 시스템을 확인하는 호환성 검사가 있습니다. 여기서 문제가되는 경우 ext3 에 대한 수표를 추가해야할까요?

편집하다:
참고로; daemon / graphdriver / overlay / overlay.go # L115

thaJeztah 에 2015년 06월 16일

루프 드라이버는 폐기가 들어올 때 파일에 구멍을 뚫기 위해 fallocate ()를 사용합니다. fallocate ()의 Linux man 페이지는 ext3에서 지원되지 않는지 확인합니다.

/ *
모든 파일 시스템이 FALLOC_FL_PUNCH_HOLE을 지원하는 것은 아닙니다. 파일 시스템이 작업을 지원하지 않으면 오류가 반환됩니다. 이 작업은 최소한 다음 파일 시스템에서 지원됩니다.
* XFS (Linux 2.6.38부터)
* ext4 (Linux 3.0부터)
* Btrfs (Linux 3.7부터)
* tmpfs (Linux 3.5부터)
* /

rhvgoyal 에 2015년 06월 16일

뿡 빵뀨

누군가가 ext3에서 도커를 실행하고 싶다면 그것을 허용해야한다고 생각합니다. 폐기 지원을받지 않으므로 이미지 / 컨테이너가 삭제 될 때 루프 파일 크기가 줄어들지 않습니다.

rhvgoyal 에 2015년 06월 16일

@rhvgoyal docker info 이것을 보여주는 것은 어떻습니까? Udev Sync Supported 출력과 유사합니다.

thaJeztah 에 2015년 06월 16일

뿡 빵뀨

이미 docker info "Backing filesystem"에 항목이 있습니다. ext2 / ext3 / ext4에 대해 정확하지 않고 왜 extfs라고 말하는지 잘 모르겠습니다.

로그에서 시작시 경고가 될 수 있습니다. 씬 풀에 루프 장치 사용에 대한 경고와 유사한 것입니다.

rhvgoyal 에 2015년 06월 16일

뿡 빵뀨

많은 사람들이 이로 인해 영향을받는 경우에만해야한다고 생각합니다. 그렇지 않다면 우리는 단지 더 많은 작업과 코드를 만들고 있으며 그만한 가치가 없을 수도 있습니다.

rhvgoyal 에 2015년 06월 16일

ext2, ext3 및 ext4에있는 Type 필드가있는 syscall.Statfs_t 구조체는 모두 0xef53 반환하며 이것이 파일 시스템 마법을 감지하는 데 사용하는 것입니다.

vbatts 에 2015년 06월 16일

ext2, ext3 및 ext4의 Type 필드가있는 syscall.Statfs_t 구조체는 모두 0xef53을 반환하며 이것이 파일 시스템 마법을 감지하는 데 사용하는 것입니다.

Bummer. 보고 된 문제를 더 쉽게 식별 할 수 있도록 해당 정보가 있으면 좋았을 것입니다.

그럼 이걸 닫아야 겠어요?

thaJeztah 에 2015년 06월 16일

이것은 ext3가 오래된 문제이므로 닫습니다. ext4 또는 xfs를 사용하십시오

vbatts 에 2015년 06월 16일

이것이 어떻게 든 기본 Docker 문서에 더 잘 문서화 될 수 있다고 생각하십니까?

문제가 파일 시스템에 있는지 여부에 관계없이 이것이 최근 두 가지 문제에서 얼마나 많은 혼란을 불러 일으켰는지 살펴보십시오.

감사.

dbabits 에 2015년 06월 17일

# 9786 문제로 돌아 가기

dbabits 에 2015년 06월 17일

@dbabits 예, ext3에 몇 가지 문제가 있다고 언급하는 것이 문서에서 언급 할 가치가 있다고 생각합니다. 적절한 위치가 무엇인지 아직 모릅니다.

thaJeztah 에 2015년 06월 17일

XFS와 동일하거나 유사한 문제가 있습니다.
커널 "3.10.0-123.el7.x86_64"에 있었지만 이제 "3.10.0-229.el7.x86_64"에서 업데이트되었습니다.

Eveything은 삭제되지만 (컨테이너, 이미지) 데이터에는 여전히 100GB가 포함됩니다.
어떤 아이디어, 도움?

[ root @ docker0101 ~] # ls -alh / data / docker / devicemapper / devicemapper /
총 80G
drwx ------ 2 루트 루트 32 6 월 8 일 16:48.
drwx ------ 5 루트 루트 50 Jun 9 07:16 ..
-rw ------- 1 루트 루트 100G Jul 16 21:33 데이터
-rw ------- 1 루트 루트 2.0G Jul 17 09:20 메타 데이터

[ root @ docker0101 ~] # uname -a
Linux docker0101 3.10.0-229.7.2.el7.x86_64 # 1 SMP 6 월 23 일 화요일 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

[ root @ docker0101 ~] # 고양이 / etc / redhat-release
CentOS Linux 릴리스 7.1.1503 (코어)

[ root @ docker0101 ~] # docker ps -a
컨테이너 ID 이미지 명령 생성 상태 포트 이름

[ root @ docker0101 ~] # 도커 이미지 -a
저장소 태그 이미지 ID가 생성 된 가상 크기

[ root @ docker0101 ~] # 도커 정보
컨테이너 : 0
이미지 : 0
스토리지 드라이버 : devicemapper
풀 이름 : docker-253 : 0-268599424-pool
풀 블록 크기 : 65.54 kB
백업 파일 시스템 : xfs
데이터 파일 : / dev / loop0
메타 데이터 파일 : / dev / loop1
사용 된 데이터 공간 : 85.61GB
총 데이터 공간 : 107.4GB
사용 가능한 데이터 공간 : 40.91MB
사용 된 메타 데이터 공간 : 211.4MB
총 메타 데이터 공간 : 2.147GB
사용 가능한 메타 데이터 공간 : 40.91MB
Udev 동기화 지원 : true
데이터 루프 파일 : / data / docker / devicemapper / devicemapper / data
메타 데이터 루프 파일 : / data / docker / devicemapper / devicemapper / metadata
라이브러리 버전 : 1.02.93-RHEL7 (2015-01-28)
실행 드라이버 : native-0.2
커널 버전 : 3.10.0-229.7.2.el7.x86_64
운영 체제 : CentOS Linux 7 (코어)
CPU : 4
총 메모리 : 11.58GiB
이름 : docker0101

[ root @ docker0101 ~] # dmsetup 테이블
vg1-lvol0 : 0 167772160 선형 8:16 2048
docker-253 : 0-268599424-pool : 0 209715200 thin-pool 7 : 1 7 : 0 128 32768 1 skip_block_zeroing

[ root @ docker0101 ~] # dmsetup 상태
vg1-lvol0 : 0 167772160 선형
docker-253 : 0-268599424-pool : 0 209715200 thin-pool 71359 51606/524288 1306264/1638400-ro waste_passdown queue_if_no_space

[ root @ docker0101 ~] # cat / etc / sysconfig / docker-storage
DOCKER_STORAGE_OPTIONS =

[ root @ docker0101 ~] # rpm -qi 도커
이름 : 도커
버전 : 1.6.2
출시 : 14.el7.centos
아키텍처 : x86_64
설치 날짜 : 2015 년 7 월 17 일 금요일 09:19:54 CEST
그룹 : 지정되지 않음
사이즈 : 33825026
라이선스 : ASL 2.0
서명 : RSA / SHA256, Wed 24 Jun 2015 05:43:12 AM CEST, 키 ID 24c6a8a7f4a80eb5
소스 RPM : docker-1.6.2-14.el7.centos.src.rpm
빌드 날짜 : Wed 24 Jun 2015 03:52:32 AM CEST
빌드 호스트 : worker1.bsys.centos.org

[root @ docker0101 ~] # ls -al / var / lib / docker
lrwxrwxrwx 1 루트 루트 12 Jun 9 08:21 / var / lib / docker-> / data / docker

[ root @ docker0101 ~] # 마운트
/ var 유형 xfs의 / dev / sda5 (rw, relatime, attr2, inode64, noquota)
/ data 유형 xfs의 / dev / mapper / vg1-lvol0 (rw, relatime, attr2, inode64, noquota)

tomlux 에 2015년 07월 17일

@tomlux 사용중인 http://www.projectatomic.io/docs/docker-storage-recommendation/을 읽는 것이 좋습니다

모든 시스템 업데이트를 적용했다고 가정하면 더 나은 성능을 얻을 수 있으며 이와 같은 문제는 발생하지 않을 것입니다.

jperrin 에 2015년 07월 17일

👍1

@tomlux

ls에 "-s"를 추가 할 수 있습니까? 그러면 데이터 및 메타 데이터 파일에 할당 된 실제 블록이 제공됩니다. 지금은 파일의 명백한 크기를 보여주고 있습니다.

도커 정보 출력은 흥미 롭습니다. 사용량이 많은 것 같습니다.

rhvgoyal 에 2015년 07월 17일

ocr

tomlux 에 2015년 07월 17일

@tomlux

따라서 데이터 및 메타 데이터 파일의 실제 크기는 작아 보입니다. 크기를 더 쉽게 읽을 수 있도록 "ls -alsh"를 사용할 수 있습니다.

따라서 데이터 파일 크기는 약 79MB이고 메타 데이터 파일 크기는 약 202KB입니다.

사용 된 블록 수에 대한 씬 풀의 통계가 왠지 옳지 않은 것 같습니다. 시스템을 재부팅하면 문제가 해결됩니까?

rhvgoyal 에 2015년 07월 17일

커널 업데이트 후 재부팅을 성공하지 못했습니다.

tomlux 에 2015년 07월 17일

좋아, 그래서 루프 파일은 크고 풀은 사용 된 블록이 많이 있다고 생각합니다. 그래서 무언가가 그 블록을 사용하고 있습니다. 나에게 출력을 줄 수 있습니까?

도커 ps -a
도커 이미지
ls / var / lib / dokcer / devicemapper / metadata / | 화장실 -l
Docker를 종료하고 다음을 실행하십시오.
thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "장치 dev_id"| 화장실 -l

이는 풀에있는 씬 디바이스의 수를 알려줍니다.

rhvgoyal 에 2015년 07월 17일

흠,
이제 DEAD 컨테이너는 있지만 이미지는 없습니다.
이미 재부팅했습니다.

devicemapper에 문제가있는 것 같습니다.
이 문제를 스팸하고 싶지 않습니다.
"rm -f / var / lib / docker"를 사용하여 컨테이너를 다시 빌드 할 수도 있습니다. 모든 것이 스크립팅됩니다.

tomlux 에 2015년 07월 17일

"dmsetup 상태"수행

수영장의 상태가 좋지 않아 수리가 필요할 가능성이 높습니다.

rhvgoyal 에 2015년 07월 17일

tomlux 에 2015년 07월 17일

안녕하세요,

Ubuntu 14.04에서도 동일한 문제가있는 것 같습니다. 그러나 원치 않는 볼륨이 발생한 원인은 블로그 http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/ 참조). 명령 실행

docker run -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker:/var/lib/docker --rm martin/docker-cleanup-volumes

많은 디스크 공간을 확보했습니다.

swachter 에 2015년 08월 17일

👍4

이것은 의미있는 방식으로 수정되지 않았습니다. 완전한 최신 Ubuntu 14.04.x 설치 (최신 LTS 릴리스) 및 최신 버전의 Docker ( $ wget -qO- https://get.docker.com/ | sh 를 통해 설치됨)에서 Docker는 쉽게 회수 할 수없는 공간을 계속 누수합니다. docker stop $(docker ps -q) && docker rm $(docker ps -q -a) && docker rmi $(docker images -q) 는 소량의 공간 만 해제합니다.

모든 공간을 회수하는 유일한 방법은 다음 해킹을 사용하는 것입니다.

$ sudo service docker stop
$ sudo rm -rf /var/lib/docker
$ sudo service docker start

그런 다음 필요한 이미지를 다시 가져와야합니다.

bkeroackdsc 에 2015년 08월 17일

😕1

@bkeroackdsc 이 공간이 "분리 된"볼륨과 관련 될 수도 있습니까?

thaJeztah 에 2015년 08월 17일

@bkeroackdsc에 동의합니다.
나는 @rhvgoyal에게 왜 그가이 사건을
결국 나는이 문제로 인해 docker에서 떨어졌습니다.
이 제품을 죽이고 있습니다.

고아 또는 고아가 아닌 경우 공간을 정리하는 좋은 방법은 없습니다.
정리를위한 docker cli 옵션, 좋은 상태 보고서 cli 옵션 및이 문제가 여러 플랫폼에서 너무 많은 사람들에게 발생하므로 디스크 공간에 대한 일종의 모니터링이 필요합니다.

sagiegurari 에 2015년 08월 18일

트윗 담아 가기

내가 묻는 이유는 고아 볼륨이이 문제와 관련이 없다는 것입니다 .
devicemapper와 관련이 없습니다 .

고아 볼륨은 버그 가 아니라 볼륨이 정의한 오해입니다.
컨테이너의 경우 컨테이너가 삭제되면 자동으로 삭제됩니다.
볼륨이 데이터를 포함 할 수 있기 때문에 이것은 케이스가 아닙니다.
컨테이너가 삭제 된 후에도 유지되어야합니다.

_ 컨테이너와 함께 볼륨을 삭제하려면 _ docker rm -v [mycontainer] .
볼륨 관리 기능이 추가됩니다 (https://github.com/docker/docker/pull/14242 및 https://github.com/docker/docker/issues/8363 참조).
"분리 된"볼륨을 관리 할 수 있습니다.

/var/lib/docker 의 증가하는 크기가 표시가 될 필요는 없습니다.
해당 디렉토리의 크기가 커지므로 devicemapper가 데이터를 유출하고 있습니다.
정리되지 않은 (분리 된) 볼륨의 결과 일 수도 있습니다.
사용자에 의해 (docker는 모든 데이터를 해당 경로에 저장합니다).

thaJeztah 에 2015년 08월 18일

이 두 항목이 필요한 기능을 제공하기를 정말로 바랍니다.
두 번째 항목은 이해했지만 첫 번째 항목 (# 14242)은 볼륨 API (어떤 기능을 제공하는지 확실하지 않음) 외에 다른 항목에 대해 설명하지 않습니다.

sagiegurari 에 2015년 08월 18일

@sagiegurari ~~이미지~~ 볼륨 관리를 구현하기위한 요구 사항의 일부입니다 (다른 공개 PR 문제가 있습니다). 최종 목표는 볼륨을 사용하는 컨테이너와 별도로 생성 / 삭제 / 관리 할 수있는 Docker의 최고 수준의 볼륨을 만드는 것입니다.

thaJeztah 에 2015년 08월 18일

@swachter 해결 방법을 게시 해 주셔서 감사합니다. 앞서 언급 한 이미지로 6GB를 회수했습니다.

rxacevedo 에 2015년 08월 18일

이탈률이 높은 도커 호스트에서 서비스 시간이 초과되기 전에 도커 데몬이 시작되지 않았기 때문에 더티 해킹으로 볼륨 누수 문제를 해결했습니다.

PRODUCTION [[email protected] ~]$ cat /etc/systemd/system/docker.service.d/docker-high-churn.conf 
[Service]
ExecStartPre=-/bin/rm -rf /var/lib/docker/containers
ExecStopPost=-/bin/rm -rf /var/lib/docker/volumes

미리 캐시 된 이미지를 플러시하지 않고 문제를 해결합니다.

nathwill 에 2015년 08월 18일

😄1

누출량 문제를 별도의 문제에서 논의 할 수 있습니까? 여기서 논의하면 장치 매퍼 문제라는 인상을받을 수 있지만 그렇지 않습니다.

rhvgoyal 에 2015년 08월 25일

트윗 담아 가기

CentOS 7 상자에서 어떤 일이 발생하는지 결론에 도달 한 적이 있습니까? 내 도커 호스트는 거의 동일하고 동일한 문제가 발생했습니다. @rhvgoyal 이 thin_dump 명령을 실행하도록 요청한 지점까지 이어졌습니다. 그 후 도커 데몬을 시작하려고했는데 시작되지 않았습니다. 나는 방금 / var / lib / docker를 삭제하고 그 이후로 다시 시작했지만, 내가 (그리고 다른 사람들도) 다시 실행할 수있는 해결책이 발견되었는지 알고 싶었습니다.

[root<strong i="11">@Docker_Sandbox_00</strong> devicemapper]# thin_dump /var/lib/docker/devicemapper/devicemapper/metadata | grep "device dev_id" | wc -l
102

[root<strong i="14">@Docker_Sandbox_00</strong> devicemapper]# systemctl start docker
Job for docker.service failed. See 'systemctl status docker.service' and 'journalctl -xn' for details.
 [root<strong i="15">@Docker_Sandbox_00</strong> devicemapper]# systemctl -l status docker.service
docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled)
   Active: failed (Result: exit-code) since Tue 2015-10-27 08:24:47 PDT; 37s ago
     Docs: https://docs.docker.com
  Process: 45244 ExecStart=/usr/bin/docker daemon -H fd:// (code=exited, status=1/FAILURE)
 Main PID: 45244 (code=exited, status=1/FAILURE)

Oct 27 08:24:45 Docker_Sandbox_00 systemd[1]: Starting Docker Application Container Engine...
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.512617474-07:00" level=info msg="[graphdriver] using prior storage driver \"devicemapper\""
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.526637164-07:00" level=info msg="Option DefaultDriver: bridge"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.526719113-07:00" level=info msg="Option DefaultNetwork: bridge"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.589016574-07:00" level=warning msg="Running modprobe bridge nf_nat br_netfilter failed with message: modprobe: WARNING: Module br_netfilter not found.\n, error: exit status 1"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.625324632-07:00" level=info msg="Firewalld running: true"
Oct 27 08:24:47 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:47.142468904-07:00" level=fatal msg="Error starting daemon: Unable to open the database file: unable to open database file"
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: Failed to start Docker Application Container Engine.
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: Unit docker.service entered failed state.

[root<strong i="18">@Docker_Sandbox_00</strong> devicemapper]# df -ah
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vdb1                                    20G   20G   24K 100% /var/lib/docker
[root<strong i="19">@Docker_Sandbox_00</strong> devicemapper]# du -sh /var/lib/docker/devicemapper/devicemapper/data
20G     /var/lib/docker/devicemapper/devicemapper/data

brian-dlee 에 2015년 10월 27일

트윗 담아 가기

내 문제의 원인을 찾았습니다. 어떻게 보였지만 스레드의 문제와 관련이 없었습니다. 도 커가 작동하는 방식에 대한 오해에서 비롯된 것입니다. 결국 죽은 컨테이너는 실행 중에 할당 한 디스크 공간을 여전히 보유하고있었습니다. 디스크 공간을 확보하기 위해 모든 컨테이너 시체를 제거해야했습니다. 이 스레드에서이 문제가 발생하는 것을 기억하지만 컨테이너가 할당 한 디스크 공간이 아닌 마운트 된 볼륨으로 만 간주됩니다.

# Beware this removes ALL containers
docker rm -f $(docker ps -aq)

@tomlux docker ps -a 의 출력에 여러 개의 Dead 컨테이너가 표시 되었기 때문에 이것이 문제 일 수도 있습니다.

brian-dlee 에 2015년 10월 29일

docker rm은 컨테이너의 디스크 공간을 확보하지 않습니다.

OS X VirtualBox의 최신 boot2docker. OS X가 완전히 패치되었습니다.

팻 (47GB) 컨테이너를 만들고 있는데 컨테이너를 다시 빌드해야한다는 문제가 있습니다. 그래서 컨테이너를 중지하고 docker rm을 수행했습니다. docker ssh를 사용하여 재확인'df -h', 디스크 사용량은 여전히 47GB입니다. 컨테이너에는 75GB가 있습니다.

따라서 도커 VM을 다시 종료해야합니다.

우리가 할 수 있습니까?

awolfe-silversky 에 2016년 01월 29일

@ awolfe-silversky는 VM이 반환 된 디스크 공간 _inside_입니까? VM 외부에있는 경우 관련이 없을 수 있습니다.

thaJeztah 에 2016년 01월 29일

@ awolfe-silversky도; _image_도 제거 했습니까? 이미지가 여전히 존재하는 경우 컨테이너 만 제거하면 큰 도움이되지 않을 수 있습니다.

thaJeztah 에 2016년 01월 29일

@ awolfe-silversky이 문제는 devicemapper에 관한 것입니다. docker-machine / boot2docker를 사용하는 경우 aufs 실행할 가능성이 훨씬 더 높습니다. 나는 또한 당신이 당신의 큰 이미지를 docker rmi 했는지 궁금합니다.

docker images 및 docker info 하여 소리를내는 것만 큼 상황이 정말 무서운지 확인하십시오. :)

(예, 여전히 vm이 있고 이미지가 제거 된 경우 이상한 코너 케이스를 발견 했으므로 새 문제를 열고 추가로 디버그해야합니다.)

SvenDowideit 에 2016년 01월 29일

이미지를 제거하지 않았습니다. 내부 도커 레지스트리에서 가져온 것입니다.
awk 스크립트를 사용하여 총 6.9GB의 이미지 크기를 조정했습니다.

docker images -a | awk '(FNR > 1) { imgSpace = imgSpace + $(NF - 1); }
END { print "Image space is " imgSpace; }'
Image space is 6909.01

더럽지 만 모든 이미지 크기가 MB 단위라는 것을 알고 있습니다.

사용을 진단하는 방법은 다음과 같습니다.

 file:///Andrew-Wolfe-MacBook-Pro.local/Users/awolfe/DataStores
awolfe_10063: docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

 file:///Andrew-Wolfe-MacBook-Pro.local/Users/awolfe/DataStores
awolfe_10064: docker-machine ssh 'awolfe-dbhost' 'df -h'
Filesystem                Size      Used Available Use% Mounted on
tmpfs                     7.0G    123.8M      6.9G   2% /
tmpfs                     3.9G         0      3.9G   0% /dev/shm
/dev/sda1                71.0G     47.2G     20.2G  70% /mnt/sda1
cgroup                    3.9G         0      3.9G   0% /sys/fs/cgroup
none                    464.8G    379.9G     84.8G  82% /Users
/dev/sda1                71.0G     47.2G     20.2G  70% /mnt/sda1/var/lib/docker/aufs

awolfe-silversky 에 2016년 01월 29일

지금은 이미지가없는 상자가 있습니다.
docker volume ls -qf dangling=true 는 아무것도 표시하지 않습니다.
docker volume ls 은 (는) 소유 할 이미지가 없기 때문에 정의상 고아 인 많은 볼륨을 보여줍니다.
docker volume rm $(docker volume ls) 는 다음과 같은 많은 메시지를 보여줍니다.

Error response from daemon: get local: no such volume
Error response from daemon: Conflict: remove 6989acc79fd53d26e3d4668117a7cb6fbd2998e6214d5c4843ee9fceda66fb14: volume is in use - [77e0eddb05f2b53e22cca97aa8bdcd51620c94acd2020b04b779e485c7563c57]

장치 매퍼 디렉토리는 30GiG를 차지합니다.
Docker 버전 1.10.2, 빌드 c3959b1
CentOS 7, 3.10.0-327.10.1.el7.x86_64

ror6ax 에 2016년 03월 14일

👍2

Data Space Used: 33.33 GB
 Data Space Total: 107.4 GB
 Data Space Available: 915.5 MB
 Metadata Space Used: 247 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 915.5 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.107-RHEL7 (2015-12-01)

또한 기본 설치에서 '적극 권장하지 않는'스토리지 옵션을 사용하는 이유는 무엇입니까?
설치시 왜 그렇게 말하지 않았습니까?

ror6ax 에 2016년 03월 14일

Amazon Linux EC2 인스턴스에서 똑같은 문제가 있습니다.

Linux ip-172-31-25-154 4.4.5-15.26.amzn1.x86_64 #1 SMP Wed Mar 16 17:15:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

정기적으로 새 도커 이미지를 설치하는 경우 유일한 해결책은 다음을 수행하는 것입니다.

service docker stop
yum remove docker -y
rm -rf /var/lib/docker
yum install docker -y
service docker start

프로덕션 환경에서는 그런 것이 허용되지 않는다고 생각합니다.

추가 정보 :

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G   20G     0 100% /

ir-fuel 에 2016년 04월 23일

👍20

이 버그는 수년 동안 존재하고 아직 닫히지 않은 것처럼 보이므로 devidemapper에 대한 docker 문서에 모든 docker 정보를 안전하게 파괴하는 방법을 넣을 수 있습니까?
내 말은,이 페이지에서 : https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
"Cleaning device mapper"와 그 방법을 입력하십시오.

나는 rm -rf / var / lib / docker를 시도 할 것이지만 그렇게하는 것이 불편하지 않다. 누군가가 안전한지 말해 줄 수 있습니까?

나는 매일 랩톱에서 젠투 리눅스를 사용하고 있으며 학습을 위해 도커를 시도했지만 디스크를 채우고 전체 시스템을 다시 설치하는 것은 VM이 아니고 젠투를 다시 설치하는 데 시간이 걸리기 때문에 옵션이 아닙니다.

수고 해주셔서 감사합니다.

mercuriete 에 2016년 05월 21일

👍8

@mercuriete dev 컴퓨터에서 docker를 제거하고 디렉토리를 삭제하고 다시 설치하십시오. 잘 작동합니다.

ir-fuel 에 2016년 05월 21일

👎22 😕7 👍3 ❤1 🎉1

@ ir-fuel : 방금 그렇게했고 이제 다음과 같이합니다.

$ sudo service docker-engine start
Redirecting to /bin/systemctl start  docker-engine.service
Failed to start docker-engine.service: Unit docker-engine.service failed to load: No such file or directory.
$ uname -a
Linux CentOS7 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

aleks-f 에 2016년 05월 22일

service docker start

ir-fuel 에 2016년 05월 22일

👍2

@ ir-fuel 감사합니다. 잘 작동합니다. : +1 :

mercuriete 에 2016년 05월 27일

디스크 공간을 해제하기 위해 docker를 다시 설치하는 것은이 문제에 대한 해결책을 찾는 동안 내가 만난 가장 어리석은 대답입니다. 이는 시간 낭비 일뿐만 아니라 대부분의 환경에서도 허용되지 않습니다. 시간제 근로자 인 경우 급여를받는 좋은 방법입니다.

asarkar 에 2016년 06월 22일

👍19 ❤2

완전히 동의 해. Docker와 같은 제품이 제거 / 재설치를 제외하고는 할 수있는 일이없이 디스크 공간을 계속해서 소모한다는 것은 놀랍습니다.

ir-fuel 에 2016년 06월 23일

👍2

이 문제를 다시 확인하여 아무것도 변경되지 않았는지 확인하십시오. +1

ror6ax 에 2016년 06월 23일

이 문제는 종결 된 것으로 표시됩니다. 우리는 해결책이 필요합니다. 해결 방법이나 재구성이 없습니다. 실제 상태는 무엇이며 관련된 구성 설정은 무엇입니까? 프로덕션 Docker 노드를 삭제하고 다시 만드는 것은 허용되지 않습니다.

awolfe-silversky 에 2016년 06월 23일

👍7

그리고 대안은 무엇입니까? 이것을 피하려면 어떻게해야합니까?

ir-fuel 에 2016년 06월 23일

이 기능을 사용하는 것이 권장되지 않는 경우-자동이며 기본값 인 이유
하나? devicemapper를 사용하는 사람들을 신경 쓰지 않는다면-나는 괜찮을 수도 있습니다.
이것으로. 그러나 사용자에게 그것에 대해 알려주십시오! 당신은 양을 알고 있습니까
이 놀라운 '해결 방법'으로 인해 사람들이 두통을 겪고 있습니까 ??
2016 년 6 월 23 일 오후 4:32, "kpande" [email protected] 은 다음과 같이 썼습니다.

해결 방법은 도커 장치 매퍼 드라이버를 사용하지 않는 것입니다.
운수 나쁘게.
—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/3182#issuecomment -228068397 또는 음소거
실
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

ror6ax 에 2016년 06월 23일

👍6 👎3

항상 rkt가 있습니다 …

blalor 에 2016년 06월 23일

👍6

일반적으로 나쁜 도움이되지 않는 snark는 의심 할 여지없이 업스트림의 아무도 적절한 답변을 제공하지 않는 이유입니다.

ripienaar 에 2016년 06월 23일

아무도 Docker를 사용하도록 강요하지 않았습니다.

이는 Oracle이 Java 개발자에게 JVM 버그로 인해 PHP를 사용하라고 말하는 것과 같습니다. 여기 엘리베이터 피치와도 일치하지 않습니다.

3 년 전 Docker는 컨테이너화라는 난해한 Linux 커널 기술을 간단하고 누구나 액세스 할 수 있도록 만들었습니다.

많은 사람들이 Docker가 그랬던 것처럼 떠났고 커뮤니티의 자원 봉사 없이는 일어날 수 없었던 것에 대해 감사하고 있다고 확신합니다. 그러나 누군가가 좋지 않은 점을 언급 할 때마다 "나는 업스트림 기여자이므로 닥치고 들어라"라는 문구를 암시 적으로 삭제하지 않고서도 문제가 있다는 것을 인정하는 것이 그렇게 어렵지 않아야합니다.

asarkar 에 2016년 06월 24일

👍20 🎉4

기다림. 내 컴퓨터 및 설정에 대한 세부 정보를 제공하고 문제를보고했습니다.
나는 의무가 없습니다. 개발자 팀 중 누구도 나와 다른 버그에 응답하지 않았습니다.
반년 동안보고합니다. 이제이 사실을 말했어, 넌 내 행동이라고 불러
암캐? 오픈 소스도 있습니까? 작업 할 Go 프로젝트를 찾고 있습니다.
Docker가 아닙니다. 이것이 당신의 목표입니까?
2016 년 6 월 23 일 16:45에 "gregory grey" [email protected]이 작성했습니다.

이 기능을 사용하는 것이 권장되지 않는 경우-자동이며 기본값 인 이유
하나? devicemapper를 사용하는 사람들을 신경 쓰지 않는다면-나는 괜찮을 수도 있습니다.
이것으로. 그러나 사용자에게 그것에 대해 알려주십시오! 당신은 양을 알고 있습니까
이 놀라운 '해결 방법'으로 인해 사람들이 두통을 겪고 있습니까 ??
2016 년 6 월 23 일 오후 4:32, "kpande" [email protected] 은 다음과 같이 썼습니다.
해결 방법은 도커 장치 매퍼 드라이버를 사용하지 않는 것입니다.
운수 나쁘게.
—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/3182#issuecomment -228068397,
또는 스레드 음소거
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

ror6ax 에 2016년 06월 24일

👎8 👍2

우선이 문제가 계속되면 새 문제를여십시오.

기다림. 나는 문제를보고했다

3 년이 지난 종결 된 문제에 대해 답변했습니다. 위의 논의에 따라 원래 문제가 해결되었습니다. 귀하의 문제는 동일 할 수도 있지만 확인하려면 더 많은 연구가 필요합니다. reporing하는 오류는 실제로 다른 것일 수 있음을 나타냅니다.

마감 된 이슈에 대해서는 언급하지 않고 새로운 이슈를 개설하는 것이 좋습니다.

내 컴퓨터 및 설정에 대한 세부 정보를 제공했지만 의무 사항이 아닙니다.

당신은 _ 의무 된 _ 것은 아니지만 계속할 정보가 없으면 해결 될 것 같지 않습니다. 따라서 버그를보고 할 때 템플릿에 요청 된 정보를 포함하십시오.
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

개발팀 중 누구도 반년 동안 저와 다른 사람들의 버그 보고서에 응답하지 않았습니다.

"관리자 중 한 명"을 의미하는 경우, 거의 24000 개의 문제와 PR이 있고 20 명 미만의 유지 관리자가 있으며 대부분의

이 기능을 사용하는 것이 권장되지 않는 경우-왜 자동이고 기본 기능입니까?

_aufs_, _btrfs_ 및 _zfs_가 지원되지 않는 경우 기본값입니다. 드라이버를 선택할 때 사용되는 우선 순위를 찾을 수 있습니다. daemon / graphdriver / driver_linux.go를 참조하십시오. 안타깝게도 _some_ 사람들이 영향을받을 수있는 드라이버와 관련된 몇 가지 문제가 남아 있기 때문에 여전히 오버레이 위에 있습니다.

그래프 드라이버를 자동으로 선택하는 것은 단순히 "실행"하는 것입니다. _your_ 상황에 가장 적합한 드라이버는 _your_ 사용 사례에 따라 다릅니다. Docker는 해당 결정을 자동으로 내릴 수 없으므로 이는 사용자가 구성해야합니다.

devicemapper를 사용하는 사람들을 신경 쓰지 않는다면-이것으로도 괜찮을 수도 있습니다.

위의 논의를 다시 읽어 보면, 업스트림 devicemapper 유지 관리자가이 _ 여러 번 _ 조사하여 사용자가 이러한 문제를보고하고 문제를 해결하도록 돕고 있음을 알 수 있습니다. 이 문제는이를보고 한 사용자 또는 경우에 따라 distros 업데이트 장치 매퍼 버전에 따라 해결되었습니다. 나는 그것이 "배려하지 않는"것으로 간주 될 수 있다고 생각하지 않습니다.

또한 기본 설치에서 '적극 권장하지 않는'스토리지 옵션을 사용하는 이유는 무엇입니까?

루프 장치에서 실행하는 것은 docker를 실행하는 데 적합하며 현재는 devicemapper를 자동으로 설정하는 유일한 방법입니다. 프로덕션 및 전반적인 성능 향상을 위해 스토리지 드라이버 사용 설명서의 devicemapper 섹션 에 설명 된대로 direct-lvm을 사용하십시오.

설치시 왜 그렇게 말하지 않았습니까?

실제로 설치 범위를 벗어났습니다. 프로덕션에서 일부 소프트웨어를 사용하려는 경우 해당 소프트웨어에 익숙해지고 사용 사례에 맞게 설정하는 데 필요한 사항을 알고 있다고 가정하는 것이 합리적이어야합니다. 일부 관리자는 경고가 출력되어야하는지 여부를 주장하기도했습니다. Linux는 "손잡이"OS가 아닙니다 (배포판에 RAID-0을 사용하는 경우 데이터 손실이 발생할 수 있다는 경고가 표시됩니까? 방화벽에 포트가 열려있는 경우?)

thaJeztah 에 2016년 06월 24일

👍32 👎3

이것은 tldr에서 나의 최선의 노력입니다. 전체 스레드에 대해; 이 스레드를 찾는 다른 사람들에게 도움이되기를 바랍니다.

발생한 문제

귀하의 볼륨에는 /var/lib/docker 상당한 (그리고 증가하는) 공간이 있으며 ext3를 사용하고 있습니다.

해결

당신은 운이 없습니다. 파일 시스템을 업그레이드하거나 하단의 blowing docker away 를 참조하십시오.

발생한 문제

귀하의 볼륨에는 /var/lib/docker 있는 상당한 (그리고 증가하는) 공간이 있고 ext3를 사용하지 _ 않고 _ (예 : 현재 xfs 또는 ext4를 사용하는 시스템)

해결

표준 Docker 명령을 사용하여 장치의 공간을 확보 할 수 있습니다.

http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/ 읽기

다음 명령을 실행하십시오.

docker volume ls
docker ps
docker images

목록에 아무것도 없으면 하단의 blowing docker away 를 참조하십시오.

오래된 오래된 이미지, 사용되지 않은 컨테이너 등이 보이면 다음을 사용하여 수동 정리를 수행 할 수 있습니다.

# Delete 'exited' containers
docker rm -v $(docker ps -a -q -f status=exited)

# Delete 'dangling' images
docker rmi $(docker images -f "dangling=true" -q)

# Delete 'dangling' volumes
docker volume rm $(docker volume ls -qf dangling=true)

이것은 devicemapper에서 숨겨진 컨테이너 공간의 대부분을 회수해야합니다.

도커를 날려 버리다

작동하지 않았습니까? 당신은 운이 없습니다.

이 시점에서 가장 좋은 방법은 다음과 같습니다.

service docker stop
rm -rf /var/lib/docker
service docker start

이것은 모든 도커 이미지를 파괴합니다. 이 작업을 _ 전에 _ 유지하려는 항목을 내 보내야합니다.

위의 조언을 사용하는 데 문제가있는 경우 발생한 문제를 구체적으로 해결하고이 문제에 연결 하는 새 티켓 을

shadowmint 에 2016년 10월 27일

👍79 ❤6

rm -rf / var / lib / docker

nuke-graph-directory.sh를 사용할 수도 있습니다.

gg7 에 2016년 11월 04일

👍8

위에서 설명한대로 파일을 제거한 후 더 이상 Docker를 시작할 수 없습니다.
Mar 02 04:53:40 pmdc001b dockerd [29522] : 데몬 시작 오류 : graphdriver 초기화 오류 : open / var / lib / docker / devicemapper / devicemapper / data : 해당 파일 또는 디렉토리가 없습니다.

gdring2 에 2017년 03월 02일

CentOS 7.3에서이 문제가 발생했고 3 년 이상 존재하는 devmapper 문제를 디버깅하고 싶지 않았기 때문에이 DC / OS 가이드를 따르고 원래 패키지를 제거하고 overlayfs로 전환했으며 이제 모든 것이 잘 작동하는 것 같습니다. : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (도커 버전 17.03에 대한 ExecStart 명령을 수정해야하지만-> "dockerd --storage-driver = 오버레이 ")

Server Version: 17.03.0-ce
Storage Driver: overlay
 Backing Filesystem: extfs
 Supports d_type: true
...
Operating System: CentOS Linux 7 (Core)

(볼륨, 이미지 및 컨테이너를 제거해도 도움이되지 않았습니다. / var / lib / docker에서 항목을 삭제하면 했습니다. )

pauvos 에 2017년 03월 21일

docker system prune 실행하면 내 컴퓨터에 많은 공간이 확보되었습니다.

https://docs.docker.com/engine/reference/commandline/system_prune/

invisibleroads 에 2017년 10월 28일

👍5

음, 이건 좀 ... 절름발이 네요.

제 경우에는 Docker를 제거하고 /var/lib/docker 디렉터리를 삭제 한 후이 문제를 발견 했으므로 service docker stop ... service docker start 해당하는 항목을 실행할 수 없습니다.

내 시스템이 /var/lib/docker 삭제로 인해 공간이 해제되었다고보고하지 않는 것을 발견했습니다 (림보처럼 보이는 곳에 ~ 14GB가 앉아있었습니다).

이것에 대한 수정은 단순히 파일 시스템을 다시로드하는 것입니다. 제 경우에는 방금 재부팅했고 공간을 회수했습니다.

Noah-Huppert 에 2018년 04월 05일

나는 그것이 여전히 문제라는 것을 믿을 수 없다! 얘들 아, 난 아직 가지고있어

shahaf600 에 2019년 01월 21일

👍8 😕2

@ shahaf600 어떤 버전의 도커를 실행하고 있습니까? 위의 내 의견도 참조하십시오. https://github.com/moby/moby/issues/3182#issuecomment -228298975

세부 사항 없이는 당신의 상황에 대해 할 말이 많지 않습니다. 귀하의 케이스는 다른 문제로 인해 발생할 수 있지만 결과는 비슷합니다.

thaJeztah 에 2019년 01월 21일

좋은

liusi123 에 2020년 10월 19일

이 쓰레기 중 하나를 사서 지원 상태를 확인한 후 반환했습니다.

misterbigstuff 에 2020년 10월 19일

😄1 👎1

@misterbigstuff에 첫 번째 문제가 있습니다 ... 오픈 소스를 구입 했습니까?

darkpixel 에 2020년 10월 19일

😄1

그리고 그것을 돌려주었습니다

misterbigstuff 에 2020년 10월 19일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Moby: 장치 매퍼가 제거 된 이미지에서 여유 공간을 해제하지 않습니다.

가장 유용한 댓글

발생한 문제

해결

발생한 문제

해결

도커를 날려 버리다

모든 206 댓글

모든 컨테이너 삭제

모든 이미지 삭제

CentOS 7

이미지 정리 전

일부 도커 rmi 후

CentOS 6.6

이미지 정리 전

남은 1929 개의 이미지에서 데이터 파일 크기 확인

일부 도커 rmi 후

발생한 문제

해결

발생한 문제

해결

도커를 날려 버리다

관련 문제