Once upon a time, when using the docker pull docker.elastic.co/elasticsearch/elasticsearch:7.10.2 command to pull ES, everything was normal. However, about halfway through the pulling process, an abnormality of insufficient disk space suddenly occurred. Detailed records are as follows:
[root@localhost /]# docker pull docker.elastic.co/elasticsearch/elasticsearch:7.10.2
7.10.2: Pulling from elasticsearch/elasticsearch
ddf49b9115d7: Downloading [======> ] 11.35MB/84.72MB
e736878e27ad: Downloading [=============> ] 6.554MB/25.12MB
7487c9dcefbe: Download complete
9ccb7e6e1f0c: Downloading [==================================================>] 345.7MB/345.7MB
dcec6dec98db: Waiting
8a10b4854661: Waiting
1e595aee1b7d: Waiting
06cc198dbf22: Waiting
55b9b1b50ed8: Waiting
write /var/lib/docker/tmp/GetImageBlob549619752: no space left on device
Show your cards first,The solution is: Modify the file C:\Users\Administrator\.vagrant.d\boxes\centos - The synchronization directory of vagrant in VAGRANTSLASH-7\2004.01\virtualbox\Vagrantfile. Details are as follows:
The original original configuration of the Vagrantfile is:
Vagrant.configure("2") do |config|
config.vm.base_mac = "5254004d77d3"
config.vm.synced_folder ".", "/vagrant", type: "rsync"
end
Create a new directory C:\Users\Administrator\vagrantSync, and modify the third line of the above configuration file to:
config.vm.synced_folder "./vagrantSync", "/vagrant", type: "rsync"
Reference blog post: "After using Vagrant, I found that the virtual machine disk space was full of blood and tears" (and hereby express my gratitude to the blogger " Thanks to the chef for "cooking without salt!") ~~~~~~~~~~~~~~~~~~~~~~~~A dividing line that refuses to be salted fish- ------------------------------------------ The following is the tragic experience of the editor who worked hard to find the clues to the problem, luckily found the above blog post, and finally cured the disease: When there is an abnormality of insufficient space, use and commands to check Docker’s root directory and root directory space usage:
docker infodf -hl
[root@localhost vagrant]# docker info
......
Docker Root Dir: /var/lib/docker
[root@localhost /]# df -lh /var/lib/docker/
FilesystemSize Used Avail Use% Mounted on
/dev/sda1 40G 40G 28M 100% /
......
I used 40G so quickly, but I didn’t do anything. Is it fate?
In order to clear up this unfair injustice, I am determined to get to the bottom of it.
Next, check the remaining space in the root directory of CentOS7:
[root@localhost /]# df -hl
Filesystem Size Used Avail Use% Mounted on
devtmpfs 912M 0 912M 0% /dev
tmpfs 919M 0 919M 0% /dev/shm
tmpfs 919M 8.6M 911M 1% /run
tmpfs 919M 0 919M 0% /sys/fs/cgroup
/dev/sda1 40G 40G 28M 100% /
tmpfs 184M 0 184M 0% /run/user/1000
overlay 40G 40G 28M 100% /var/lib/docker/overlay2/825c0e959e357450e22584d4c640d86b14112b233661c61350b5c5547c41ed3a/merged
overlay 40G 40G 28M 100% /var/lib/docker/overlay2/421dcb93c267339d1748b863098df0815d71d72315dea15691bbf941a83bc468/merged
What are these two overlay2s? It took up 40G of my space!
Recalling the series of operations done before, does it correspond to the MySQL and Redis I installed? But at this time I did not find any connection between the two and the question of this article.
After trying many things and hitting walls everywhere, I tried to refer to the blog post "The disk space in the docker container storage directory is full" The default directory of docker has been changed from /var/lib/docker to /home/docker/lib/docker.
After successfully modifying the docker directory and restarting docker, use docker images and docker ps to view the previously downloaded MySQL and Redis images and their running status. , both of which have disappeared. At this time, I feel that my previous efforts in tinkering with the database may have been in vain.
In desperation, I tried to search for the reason why /dev/sda1 caused the disk to become full, and I saw an article titled "Virtual Machine Linux in Vagrant/ The article "dev/sda1 hard disk is full" provides a command to query large files:du -h --max-depth=1. I tried it in the root directory of CentOS7 and the results are as follows. :
[root@localhost /]# du -h --max-depth=1
0 ./dev
du: cannot access ‘./proc/1514/task/1514/fd/3’: No such file or directory
du: cannot access ‘./proc/1514/task/1514/fdinfo/3’: No such file or directory
du: cannot access ‘./proc/1514/fd/4’: No such file or directory
du: cannot access ‘./proc/1514/fdinfo/4’: No such file or directory
0 ./proc
8.6M ./run
0 ./sys
36M ./etc
48K ./root
130M ./var
0 ./tmp
1.2G ./usr
27M ./boot
477M ./home
0 ./media
0 ./mnt
0 ./opt
0 ./srv
36G ./vagrant
208M ./mydata
40G .
When I saw "36G ./vagrant" in the results, my eyes suddenly lit up. Is ./vagrant the crux of the problem? I was actually a little excited at that time! So, hurry up and follow:
[root@localhost /]# cd ./vagrant/
[root@localhost vagrant]# ls
20201119_222738.mp4 Music source
20201204_215951.mp4 My Documents SpringCloudAlibaba-xxx.mp4
20201217_224243.mp4 MySQL数据结构-xxx.mp4 SpringCloud.mp4
20201218_202319.mp4 nacos SpringCloud-xxx.mp4
3D Objects NetHood spring源码1-xxx.mp4
anaconda3 node_modules spring源码2-xxx.mp4
AppData NTUSER.DAT{
18549daa-3d78-11e9-85da-005056c00008}.TM.blf Templates
Application Data NTUSER.DAT{
18549daa-3d78-11e9-85da-005056c00008}.TMContainer00000000000000000001.regtrans-ms UIDowner
Contacts NTUSER.DAT{
18549daa-3d78-11e9-85da-005056c00008}.TMContainer00000000000000000002.regtrans-ms Vagrantfile
Cookies ntuser.ini Videos
Desktop ntuser.pol VirtualBox VMs
Documents OneDrive workspace
Downloads package-lock.json Workspaces
eclipse Pictures xxx创新型资源.mp4
EVAVEdit PrintHood 多线程-可见性、有序性、原子性.mp4
Favorites PUTTY.RND 「开始」菜单
IntelGraphicsProfiles PycharmProjects 微服务演化过程-xxx1.mp4
Links Recent 微服务演化过程-xxx2.mp4
Local Settings Redis-MySQL-锁.mp4 微服务结构设计-xxx2.mp4
logs Saved Games 微服务结构设计-xxx.mp4
MicrosoftEdgeBackups Searches
mm.cfg SendTo
Looking at these familiar file names and folders, I finally knew the main cause of the problem: these files and folders and the Vagrantfile file are located in C:\Users\Administrator.
So, I moved these video files elsewhere, restarted the virtual machine, saw a glimmer of hope, and finally freed up some space.
Then, try to re-create the Redis instance and restart:
[root@localhost /]# docker run -p 6379:6379 --name redis -v /mydata/redis/data:/data -v /mydata/redis/conf/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf
Unable to find image 'redis:latest' locally
latest: Pulling from library/redis
a076a628af6f: Pull complete
f40dd07fe7be: Pull complete
ce21c8a3dbee: Pull complete
ee99c35818f8: Pull complete
56b9a72e68ff: Pull complete
3f703e7f380f: Pull complete
Digest: sha256:0f97c1c9daf5b69b93390ccbe8d3e2971617ec4801fd0882c72bf7cad3a13494
Status: Downloaded newer image for redis:latest
874e61200f4e3f18eee354f33eb0d8340fd6110d120942895443b7cfc77b9ee3
[root@localhost /]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
874e61200f4e redis "docker-entrypoint.s…" 49 seconds ago Up 44 seconds 0.0.0.0:6379->6379/tcp redis
[root@localhost /]# cat /mydata/redis/conf/redis.conf
appendonly yes
[root@localhost /]# docker exec -it redis redis-cli
127.0.0.1:6379> get a
"12341234123"
actually successfully restored Redis, and the data was not lost! At this time, I suddenly felt confident and felt that victory was in sight!
Then try to restore MySQL:
[root@localhost mydata]# docker run -p 3306:3306 --name mysql -v /mydata/mysql/log:/var/log/mysql -v /mydata/mysql/data:/var/lib/mysql -v /mydata/mysql/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=root -d mysql:5.7
Unable to find image 'mysql:5.7' locally
5.7: Pulling from library/mysql
a076a628af6f: Already exists
f6c208f3f991: Retrying in 8 seconds
f6c208f3f991: Retrying in 5 seconds
Watching the progress above gradually come to a halt, and checking the remaining space, I found that it was full again, and my mood fell off the cliff again!
After that, check an article saying that you can change the type: " rsync" is modified to: type: "virtualbox". I tested it and found an exception when restarting the virtual machine:
mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrant
The error output from the command was:
mount: unknown filesystem type 'vboxsf'
Try installing the vagrant-vbguest plugin on the host machine:
C:\Users\Administrator>vagrant plugin install vagrant-vbguest
Installing the 'vagrant-vbguest' plugin. This can take a few minutes...
Fetching micromachine-3.0.0.gem
Fetching vagrant-vbguest-0.29.0.gem
Installed the plugin 'vagrant-vbguest (0.29.0)'!
However, the problem was not solved.
At this time, there were more and more question marks in my mind. I tried searching for "Why does vagrant treat files on the physical machine as files on the virtual machine" and accidentally discovered the blog post "Vagrant mounts the files under the C drive user into the vagrant directory, causing the virtual machine space to become full", and this article indicates the use of Vagrant later found that the virtual machine disk space was full of blood and tears "'s reference.
Follow the guidance of the above-mentioned godly article, create a new folder: C:\Users\Administrator\vagrantSync, and replace C:\Users\Administrator\.vagrant.d\boxes\centos-VAGRANTSLASH-7\2004.01 \virtualbox\Vagrantfile:
config.vm.synced_folder ".", "/vagrant", type: "rsync" is changed to: config.vm.synced_folder "./vagrantSync", "/vagrant", type: "rsync", and the problem is solved.
Question at the end of the article: Type "rsync" is said to guarantee a very high sharing speed. So, in addition to the "rsync" sharing type, are there any other types?