Installed the OpenLiteSpeed Wordpress from the DigitalOcean’s image. After month or so I’ve got the next situation. The MySQL is not started and after small research I’ve found out that there’s no space left on devices.
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 121329 399 120930 1% /dev
tmpfs 125611 625 124986 1% /run
/dev/vda1 3225600 102554 3123046 4% /
tmpfs 125611 10 125601 1% /dev/shm
tmpfs 125611 3 125608 1% /run/lock
tmpfs 125611 18 125593 1% /sys/fs/cgroup
/dev/vda15 0 0 0 - /boot/efi
/dev/loop1 10775 10775 0 100% /snap/core18/1885
/dev/loop0 70 70 0 100% /snap/bpytop/186
/dev/loop2 10779 10779 0 100% /snap/core18/1932
/dev/loop3 11573 11573 0 100% /snap/core20/634
/dev/loop4 1496 1496 0 100% /snap/lxd/16922
/dev/loop5 1551 1551 0 100% /snap/lxd/18150
/dev/loop6 472 472 0 100% /snap/snapd/10238
/dev/loop7 472 472 0 100% /snap/snapd/9721
tmpfs 125611 22 125589 1% /run/user/0
How to fix that? Thanks!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Hello, inkink
If those are simple snap images it’s not an issue to have 100% utilization of their disk space partition. They’re configured to work in this way.
If you use df
with the -T argument. Tt will display the file system type of your system along with other information.
df -T
You will see that the file system type for the snap partitions are squashfs and this is normal for this type of FS. The filesystem size is always just large enough to contain it’s contents.
Hope that this helps! Regards, Alex
Yes, I’ve found the backups at the end of searching for big files, so the issue was not in fully occupied space in /dev/loop#, but in backups folder.
you need to find out what is using the disk space, i would assume all kind of logs files you can try clean them up first.