I have a VBox VM running CentOS 6.7 and I want to extract the content of a 14G tar file. I'm doing as:
*tar -xvf www.tar.gz*
But I am getting a lot of errors like the ones shown below:
html/elclarinweb.dev/wp-content/uploads/2015/03/12-Aura-Ávila-400x320.jpg tar: html/elclarinweb.dev/wp-content/uploads/2015/03/12-Aura-Ávila-400x320.jpg: Cannot open: No space left on device html/elclarinweb.dev/wp-content/uploads/2015/03/Julianne-Moore-11-585x378.jpg tar: html/elclarinweb.dev/wp-content/uploads/2015/03/Julianne-Moore-11-585x378.jpg: Cannot open: No space left on device
So, trying to find why the VHDD (Virtual HDD) has left out of space I ran the following command:
*df -h* Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_server-lv_root 26G 24G 869M 97% / tmpfs 2.0G 0 2.0G 0% /dev/shm /dev/sda1 477M 80M 373M 18% /boot
And then I've tried to find the conflictive files by running:
*du -hsx * | sort -rh | head -10* du: cannot access `proc/3662/task/3662/fd/4': No such file or directory du: cannot access `proc/3662/task/3662/fdinfo/4': No such file or directory du: cannot access `proc/3662/fd/4': No such file or directory du: cannot access `proc/3662/fdinfo/4': No such file or directory 14G var 1.8G usr 278M lib 77M boot 31M etc 27M lib64 15M sbin 7.8M bin 188K dev 112K root
Why *df -h* is reporting 24G used? Where the space did go? How I can fix this?
On Sep 11, 2015, at 12:57 PM, reynierpm@gmail.com wrote:
html/elclarinweb.dev/wp-content/uploads/2015/03/12-Aura-Ávila-400x320.jpg: Cannot open: No space left on device
*df -h* Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_server-lv_root 26G 24G 869M 97% /
Linux boxes typically reserve the last 5% of volume space for use by root only, so as far as your normal user is concerned, the volume is in fact full.
*du -hsx * | sort -rh | head -10* du: cannot access `proc/3662/task/3662/fd/4': No such file or directory du: cannot access `proc/3662/task/3662/fdinfo/4': No such file or directory du: cannot access `proc/3662/fd/4': No such file or directory du: cannot access `proc/3662/fdinfo/4': No such file or directory
You need to be careful with commands that descend into /proc like that, because its contents changes rapidly. Here, you’ve seen that PID 3662 disappeared between the time your * glob was evaluated and the du command actually tried to run on it.
Your du -x argument says restrict to a single filesystem, but that is evaluated per FILE argument, so it doesn’t prevent du from walking off the LVM and into /proc. To do that, you’d need to say “du -hsx /”, but then you don’t get the results you want.
Instead, I’d recommend just explicitly listing the most likely pigs: /usr, /var, /home, and /etc.
14G var 1.8G usr 278M lib 77M boot 31M etc 27M lib64 15M sbin 7.8M bin 188K dev 112K root
I see about 16 GiB.
Why *df -h* is reporting 24G used? Where the space did go? How I can fix this?
24 - 16 = 8, which sounds suspiciously like the size of a swap file. What does mount say?
On Fri, Sep 11, 2015 at 2:45 PM, Warren Young wyml@etr-usa.com wrote:
24 - 16 = 8, which sounds suspiciously like the size of a swap file. What does mount say?
What do you mean with "mount says"? Can you point me on the right command to execute?
Il giorno ven, 11/09/2015 alle 14.48 -0430, reynierpm@gmail.com ha scritto:
What do you mean with "mount says"? Can you point me on the right command to execute?
Run this command :
[root@centos7 ~]# du -sc /* /.??* --exclude /proc|sort -n 0 /.autorelabel 0 /bin 0 /dev 0 /lib 0 /lib64 0 /media 0 /mnt 0 /sbin 0 /srv 0 /sys 52 /root 72 /tmp 6752 /run 22772 /etc 128940 /boot 144252 /home 150000 /var 760748 /opt 1432444 /usr 2646032 totale [root@centos7 ~]# lsblk /dev/vda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 9,8G 0 disk ├─vda1 252:1 0 500M 0 part /boot └─vda2 252:2 0 9,3G 0 part ├─centos-root 253:0 0 4,4G 0 lvm / ├─centos-swap 253:1 0 1000M 0 lvm [SWAP] ├─centos-var 253:2 0 2,2G 0 lvm /var └─centos-opt 253:3 0 1,8G 0 lvm /opt
and post the result.
On Fri, Sep 11, 2015 at 3:19 PM, Dario Lesca d.lesca@solinos.it wrote:
the result.
# du -sc /* /.??* --exclude /proc|sort -n 0 /.autofsck 0 /.autorelabel 0 /misc 0 /net 0 /sys 4 /cgroup 4 /media 4 /mnt 4 /selinux 4 /srv 8 /opt 16 /home 16 /lost+found 16 /tmp 112 /root 188 /dev 7956 /bin 14624 /sbin 27088 /lib64 31636 /etc 78796 /boot 284672 /lib 1882548 /usr 14422860 /var 16750556 total
lsblk /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 30G 0 disk ├─sda1 8:1 0 500M 0 part /boot └─sda2 8:2 0 29.5G 0 part ├─vg_server-lv_root (dm-0) 253:0 0 26.5G 0 lvm / └─vg_server-lv_swap (dm-1) 253:1 0 3G 0 lvm [SWAP]
did you (or someone else with root access) possibly delete a very large file in /var that may still have been in use? it's very annoying but if you do a rm on a large file under /var that is still open by some process for writing, it won't actually clear the space. you can overcome that by just truncating the file instead of doing an rm (e.g. either > /var/log/bigfile or cp /dev/null /var/log/bigfile). the only way I know to fix the problem once you're having it is to force the process to close/reopen the file... either by killing & restarting or getting the process to do it if it's got that designed in. in practice I've often found it much easier to reboot a machine to fix such a problem condition.
On Fri, Sep 11, 2015 at 3:52 PM, zep zgreenfelder@gmail.com wrote:
did you (or someone else with root access) possibly delete a very large file in /var that may still have been in use? it's very annoying but if you do a rm on a large file under /var that is still open by some process for writing, it won't actually clear the space. you can overcome that by just truncating the file instead of doing an rm (e.g. either > /var/log/bigfile or cp /dev/null /var/log/bigfile). the only way I know to fix the problem once you're having it is to force the process to close/reopen the file... either by killing & restarting or getting the process to do it if it's got that designed in. in practice I've often found it much easier to reboot a machine to fix such a problem condition.
In fact, that's exactly what I did. I have tried to open that 14G .tar.gz file from mc and it crashes several times so I delete the temporary files from /tmp and also from /home where originally I copied. I've rebooted the VM and now the output of df -h looks better:
# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_server-lv_root 26G 16G 8.7G 65% / tmpfs 2.0G 0 2.0G 0% /dev/shm /dev/sda1 477M 80M 373M 18% /boot
On Sep 11, 2015, at 1:18 PM, reynierpm@gmail.com wrote:
On Fri, Sep 11, 2015 at 2:45 PM, Warren Young wyml@etr-usa.com wrote:
24 - 16 = 8, which sounds suspiciously like the size of a swap file. What does mount say?
What do you mean with "mount says”?
I mean run the “mount” command. Its output is what the program “says.”
But never mind now, since you found the actual problem.
On Sep 11, 2015, at 3:32 PM, Warren Young wyml@etr-usa.com wrote:
I mean run the “mount” command. Its output is what the program “says.”
But never mind now, since you found the actual problem.
Ah, bogus command anyway. I thought swap space showed up in the mount table, but it doesn’t. swapon -s is a better command for showing what I wanted to know.
On 09/11/2015 11:57 AM, reynierpm@gmail.com wrote:
Why*df -h* is reporting 24G used? Where the space did go? How I can fix this?
This is a FAQ. For future reference, you can locate such files in Linux:
ls -l /proc/*/fd | grep deleted
Deleted files are still present in the filesystem until they are closed.
-
Dario Lesca -
Gordon Messmer -
reynierpm＠gmail.com -
Warren Young -
zep