Docker dit «il ne reste plus d'espace sur l'appareil», mais le système a beaucoup d'espace?

J'essaie d'exécuter une image de docker qui fonctionne sur d'autres systèmes (et vous pouvez même la retirer de dockerhub, si vous le souhaitez: c'est dougbtv/asterisk) cependant, sur mon poste de travail général, il se plaint de l'espace libre quand il (ressemble) c'est décompresser les images du docker.

J'essaye de l'exécuter, et quand je le fais, j'obtiens une erreur indiquant que c'est à court d'espace. Voici un exemple de moi essayant de l'exécuter, et il se plaint d'espace.

[root@localhost docker]# docker run -i -t dougbtv/asterisk /bin/bash
Timestamp: 2015-05-13 07:50:58.128736228 -0400 EDT
Code: System error

Message: [/usr/bin/tar -xf /var/lib/docker/tmp/70c178005ccd9cc5373faa8ff0ff9c7c7a4cf0284bd9f65bbbcc2c0d96e8565d410879741/_tmp.tar -C /var/lib/docker/devicemapper/mnt/70c178005ccd9cc5373faa8ff0ff9c7c7a4cf0284bd9f65bbbcc2c0d96e8565d/rootfs/tmp .] failed: /usr/bin/tar: ./asterisk/utils/astdb2sqlite3: Wrote only 512 of 10240 bytes
/usr/bin/tar: ./asterisk/utils/conf2ael.c: Cannot write: No space left on device
/usr/bin/tar: ./asterisk/utils/astcanary: Cannot write: No space left on device
/usr/bin/tar: ./asterisk/utils/.astcanary.o.d: Cannot write: No space left on device
/usr/bin/tar: ./asterisk/utils/check_expr.c: Cannot write: No space left on device
[... another few hundred similar lines]

Bien sûr, je vérifie la quantité d'espace disponible, et grâce à la recherche sur Google, je trouve que cela se produit parfois parce que vous êtes à court d'inodes. Je regarde donc les deux, et je peux voir qu'il y a aussi beaucoup d'inodes.

[root@localhost docker]# df -h
Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 3.9G     0  3.9G   0% /dev
tmpfs                    3.9G   20M  3.9G   1% /dev/shm
tmpfs                    3.9G  1.2M  3.9G   1% /run
tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/mapper/fedora-root   36G  9.4G   25G  28% /
tmpfs                    3.9G  5.2M  3.9G   1% /tmp
/dev/sda3                477M  164M  285M  37% /boot
/dev/mapper/fedora-home   18G  7.7G  8.9G  47% /home
tmpfs                    793M   40K  793M   1% /run/user/1000
/dev/sdb1                489G  225G  265G  46% /mnt/extradoze
[root@localhost docker]# df -i
Filesystem                 Inodes  IUsed     IFree IUse% Mounted on
devtmpfs                  1012063    585   1011478    1% /dev
tmpfs                     1015038     97   1014941    1% /dev/shm
tmpfs                     1015038    771   1014267    1% /run
tmpfs                     1015038     15   1015023    1% /sys/fs/cgroup
/dev/mapper/fedora-root   2392064 165351   2226713    7% /
tmpfs                     1015038    141   1014897    1% /tmp
/dev/sda3                  128016    429    127587    1% /boot
/dev/mapper/fedora-home   1166880 145777   1021103   13% /home
tmpfs                     1015038     39   1014999    1% /run/user/1000
/dev/sdb1               277252836 168000 277084836    1% /mnt/extradoze

Et donc vous pouvez voir un peu ce qui se passe, voici mon /etc/fstab

[root@localhost docker]# cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Tue Mar 17 20:11:16 2015
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/fedora-root /                       ext4    defaults        1 1
UUID=2e2535da-907a-44ec-93d8-1baa73fb6696 /boot                   ext4    defaults        1 2
/dev/mapper/fedora-home /home                   ext4    defaults        1 2
/dev/mapper/fedora-swap swap                    swap    defaults        0 0

Et j'ai également demandé à quelqu'un avec une question d'échange de pile similaire de demander les résultats de la lvscommande, qui montre:

[root@localhost docker]# lvs
  LV   VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home fedora -wi-ao---- 17.79g                                                    
  root fedora -wi-ao---- 36.45g                                                    
  swap fedora -wi-ao----  7.77g

C'est un système Fedora 21:

[root@localhost docker]# cat /etc/redhat-release 
Fedora release 21 (Twenty One)
[root@localhost docker]# uname -a
Linux localhost.localdomain 3.19.5-200.fc21.x86_64 #1 SMP Mon Apr 20 19:51:56 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Pilote de stockage:

[doug@localhost cs]$ sudo docker info|grep Driver:
Storage Driver: devicemapper
Execution Driver: native-0.2

Version Docker:

[doug@localhost cs]$ sudo docker -v
Docker version 1.6.0, build 3eac457/1.6.0

Par cet article recommandé, j'ai essayé de changer de docker en/etc/sysconfig/docker

OPTIONS='--selinux-enabled --storage-opt dm.loopdatasize=500GB --storage-opt dm.loopmetadatasize=10GB'

Et redémarré docker, en vain. Je l'ai changé en juste --selinux-enabled(note: j'ai selinux désactivé)

De plus, j'ai remarqué que l'article mentionnait la recherche du fichier de données de rechange, qui ressemble à:

[root@localhost doug]# ls -alhs /var/lib/docker/devicemapper/devicemapper
total 3.4G
4.0K drwx------ 2 root root 4.0K Mar 20 13:37 .
4.0K drwx------ 5 root root 4.0K Mar 20 13:39 ..
3.4G -rw------- 1 root root 100G May 13 14:33 data
9.7M -rw------- 1 root root 2.0G May 13 14:33 metadata

Est-ce un problème que le fichier clairsemé soit plus grand que la taille du disque?

Mes lsblklooks:

[root@localhost doug]# lsblk
NAME                        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                           8:0    0 111.8G  0 disk 
├─sda1                        8:1    0   100M  0 part 
├─sda2                        8:2    0  49.2G  0 part 
├─sda3                        8:3    0   500M  0 part /boot
├─sda4                        8:4    0     1K  0 part 
└─sda5                        8:5    0    62G  0 part 
  ├─fedora-swap             253:0    0   7.8G  0 lvm  [SWAP]
  ├─fedora-root             253:1    0  36.5G  0 lvm  /
  └─fedora-home             253:2    0  17.8G  0 lvm  /home
sdb                           8:16   0   1.8T  0 disk 
└─sdb1                        8:17   0   489G  0 part /mnt/extradoze
loop0                         7:0    0   100G  0 loop 
└─docker-253:1-1051064-pool 253:3    0   100G  0 dm   
loop1                         7:1    0     2G  0 loop 
└─docker-253:1-1051064-pool 253:3    0   100G  0 dm

fedora hard-disk docker

— dougBTV
source

Quel pilote de stockage utilisez-vous? sudo docker info|grep Driver:

— mattdm

Bonne question @mattdm, c'est devicemapperavec le pilote d'exécution native-0.2. J'ai mis à jour ma question avec cette information et la version docker.

— dougBTV

pouvez-vous joindre la sortie de lsblk? Ce billet de blog peut aider, bien qu'il soit un peu obsolète.

— mattdm

Je suis allé le mettre à jour et j'ai parcouru le blog pour vérifier quelques choses, que j'ai également notées, j'apprécie le pointeur là-bas @mattdm

— dougBTV

Docker extrait un fichier tar de / var / lib / docker / tmp / 70 .... vers un répertoire sous / var / lib / docker / devicemapper / .... Le fait qu'il y ait la sous-chaîne 'devicemapper' dans ce chemin me fait penser que docker mappe un périphérique de stockage de bloc dans un périphérique de bloc spécifique à docker à utiliser. Cela signifie probablement que si vous exécutez lsblk / df et ses amis avant ou après la commande docker, vous manquerez le périphérique mappé (le docker se nettoie après lui-même?). Je ferais probablement ctrl-z le processus de dégroupage après que les erreurs commencent à apparaître et commencent à fouiller avec les outils df / dm. Peux-tu faire ça?

— Lmwangi

Si vous utilisez un système d'exploitation basé sur Red-Hat, vous devez savoir que "Devicemapper" est limité à 10 Go par image, et si vous essayez d'exécuter une image pouvant atteindre 10 Go, vous pouvez obtenir cette erreur. C'est peut-être votre problème. Essayez ça, ça a marché pour moi

https://docs.docker.com/engine/reference/commandline/daemon/#storage-driver-options

 sudo systemctl stop docker.service

sudo service docker stop

rm -rvf /var/lib/docker (Take back up of any important data; containers and images will be deleted)

Exécutez cette commande

docker daemon --storage-opt dm.basesize=20G

Où "20G" fait référence à la nouvelle taille que vous souhaitez que le devicemapper prenne, puis redémarrez docker

sudo systemctl start docker.service

sudo service docker start

Vérifiez s'il est défini en exécutant

docker info

J'espère que cela fonctionne!

— RIcardo
source

Je vous remercie! Je vais essayer ça plus tard. J'ai toujours cette machine autour, cependant, elle est maintenant assez obsolète, il pourrait donc m'appartenir de mettre à jour Fedora & Docker.

— dougBTV

J'ai essayé, mais Docker a refusé de démarrer par la suite. Je pense que "juste ne pas utiliser redhat" serait une solution plus simple :)

— samthebest

sudo dockerd-current --storage-opt dm.basesize=20G... c'est le docker daemon => dockerd dans RedHat.

— mikiemorales

La commande docker daemon --storage-opt dm.basesize=20Gne semble plus exister.

— Alex

Êtes-vous par hasard en train de lancer une très grande image? RHEL n'a pas de support natif aufs. Vous utilisez donc devicemapper Lorsque vous utilisez devicemapper, vous n'avez accès qu'à 10 Go par défaut pour votre système de fichiers conteneur. Consultez cet article , il peut être utile.

— Aymeric
source

Bien que ce lien puisse répondre à la question, il est préférable d'inclure les parties essentielles de la réponse ici et de fournir le lien de référence. Les réponses de lien uniquement peuvent devenir invalides si la page liée change.

— Anthon

La course à pied a docker system prunefonctionné pendant un certain temps, puis j'ai dû continuer à augmenter la "Taille de l'image du disque" dans les Préférences ...> Disque, mais cela n'a aidé que jusqu'à ce que je l'augmente à nouveau.

Je refuse de continuer à augmenter la taille de l'image disque et docker system prunene réclamais plus d'espace, mais la course docker volume prunea aidé cette fois.

— AVProgrammer
source