The file system /dev/loop0, has reached critical status because it is 100% full

Question

The file system /dev/loop0, which is mounted at /tmp, has reached critical status because it is 100% full.

The problem is when I checked the space of hard disk I found that:

/dev/loop0 space:485M used:21M free:439M usage:5% /var/tmp

So what is the problem, and how can I increase the tmp folder?

this is mount result:

rootfs on / type rootfs (rw)
/dev/root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered,jqfmt=vfsv0                                               ,usrjquota=quota.user)
devtmpfs on /dev type devtmpfs (rw,relatime,size=4033140k,nr_inodes=1008285,mode                                               =755)
none on /proc type proc (rw,nosuid,nodev,noexec,relatime)
none on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/md2 on /home type ext4 (rw,relatime,data=ordered,jqfmt=vfsv0,usrjquota=quot                                               a.user)
tmpfs on /dev/shm type tmpfs (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/loop0 on /tmp type ext3 (rw,nosuid,noexec,relatime,errors=continue,barrier=                                               1,data=writeback)
/dev/loop0 on /var/tmp type ext3 (rw,nosuid,noexec,relatime,errors=continue,barr                                               ier=1,data=writeback)
/dev/root on /var/named/chroot/etc/named type ext4 (rw,relatime,errors=remount-r                                               o,data=ordered,jqfmt=vfsv0,usrjquota=quota.user)
/dev/root on /var/named/chroot/etc/named.rfc1912.zones type ext4 (rw,relatime,er                                               rors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=quota.user)
/dev/root on /var/named/chroot/etc/rndc.key type ext4 (rw,relatime,errors=remoun                                               t-ro,data=ordered,jqfmt=vfsv0,usrjquota=quota.user)
/dev/root on /var/named/chroot/usr/lib64/bind type ext4 (rw,relatime,errors=remo                                               unt-ro,data=ordered,jqfmt=vfsv0,usrjquota=quota.user)
/dev/root on /var/named/chroot/etc/named.iscdlv.key type ext4 (rw,relatime,error                                               s=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=quota.user)
/dev/root on /var/named/chroot/etc/named.root.key type ext4 (rw,relatime,errors=                                               remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=quota.user)

result of df -h /tmp:

Filesystem            Size  Used Avail Use% Mounted on
/dev/loop0            485M   21M  439M   5% /tmp

by the way from 2 days I have found database table has 13GB space I deleted it and from this time this problem has been started and server is very heavy and all sites take a lot of time to open but when I stopped the mysql service, the server became very fast.

i don't know what you mean and what is your suggest ? by the way i use centos 6 with whm cpanel and default settings — SHREEF, Jun 16 '13 at 22:52
I really hope you're not running a hosting provider on this system. — Falcon Momot, Jun 16 '13 at 23:34

score 3 · Answer 1 · answered Jun 16 '13 at 23:33

The loop0 is a loop device, which passes accesses to userspace for processing. In consequence, the reason for this behaviour depends on how you have set it up. Devices aren't constrained to reporting the actual available space, and can fail writes more or less arbitrarily.

For instance, if the loop0 device is backed by a file (eg. it's set up to be an EFS volume using a command like losetup -e aes256 -S <stuff> /dev/loop0 /root/somefile) and that file is sparse, this error can be caused by being out of space on the device on which that file resides, regardless of the reported free space. This is because the size of the backing file doesn't reflect the actual size it takes up on disk.

Additionally, if you are in a virtualized environment, a very similar principle applies: if your volume is sparse (or "thin provisioned" in VMWare parlance), and you are out of space on the physical volume backing the virtual volume, writes may fail due to being out of space regardless of the reported size of the virtual volume.

One thing you can do is use the df command to see if any volume is actually full. What volume is full depends on your exact setup though - it could be on a SAN, or on the hypervisor if any, or on the server you're having problems with, for instance. — Falcon Momot, Jun 17 '13 at 00:46

The file system /dev/loop0, has reached critical status because it is 100% full

1 Answers1