Running out of Gigs of disk space within seconds

japtar10101 · 2011-03-12 06:02:46

I can't pin-point the exact reason, but recently, a certain operation has caused my 69 Gig root partition to suddenly jumps from less than 30% used to 100% used...twice. I believe it has to do with yaourt, but it could just as easily be flash or slim at this rate.

Yesterday, when I had this problem, I ran "pacman -Sc", deleted all the old log files, and finally, rebooted. This heavily reduced the load that time (100% to 19%), but today, running "pacman -Scc" and restarting turned out to only reduce the used percentage from 100% to 95%. Any ideas why this is happening, where to amend it, and how to prevent this problem in the future?

jasonwryan · 2011-03-12 06:15:08

If it is yaourt related, it may be /tmp.

You need to narrow down where the disk space is being eaten up:

df -k

japtar10101 · 2011-03-12 06:24:58

jasonwryan wrote:

If it is yaourt related, it may be /tmp.
You need to narrow down where the disk space is being eaten up:
df -k

Like this?

$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
udev                     10240       212     10028   3% /dev
/dev/sda7             72075600  64670416   3743924  95% /
shm                    1284280       308   1283972   1% /dev/shm
/dev/sda5               253871     16188    224576   7% /boot
/dev/sda8             51605116   7032088  41951640  15% /home
/dev/sda3             41943036  22088176  19854860  53% /mnt/share
/dev/sda2            136215132  57500848  78714284  43% /mnt/windows

I've noticed var, usr, and opt seems to be pretty large. The other big folders are mounted from separate partitions.

$ sudo du -hs /*
5.7M    /bin
14M    /boot
212K    /dev
7.2M    /etc
du: cannot access `/home/japtar10101/.gvfs': Permission denied
6.6G    /home
75M    /lib
4.0K    /lib64
16K    /lost+found
4.0K    /media
75G    /mnt
2.3G    /opt
du: cannot access `/proc/4971/task/4971/fd/3': No such file or directory
du: cannot access `/proc/4971/task/4971/fdinfo/3': No such file or directory
du: cannot access `/proc/4971/fd/3': No such file or directory
du: cannot access `/proc/4971/fdinfo/3': No such file or directory
0    /proc
3.8M    /root
9.9M    /sbin
20K    /srv
0    /sys
740K    /tmp
5.5G    /usr
124M    /var


$ sudo du -hs /usr/*
354M    /usr/bin
235M    /usr/include
2.2G    /usr/lib
190M    /usr/lib32
4.0K    /usr/libexec
216K    /usr/local
12K    /usr/man
10M    /usr/sbin
2.5G    /usr/share
54M    /usr/src


$ sudo du -hs /var/*
5.4M    /var/cache
4.0K    /var/empty
12K    /var/games
112M    /var/lib
4.0K    /var/local
12K    /var/lock
6.0M    /var/log
0    /var/mail
4.0K    /var/opt
120K    /var/run
104K    /var/spool
12K    /var/tmp


$ sudo du -hs /opt/*
5.0M    /opt/doukutsu
517M    /opt/sauerbraten
112M    /opt/secondlife
431M    /opt/warsow
1.3G    /opt/xonotic

Last edited by japtar10101 (2011-03-12 06:29:30)

ijanos · 2011-03-12 08:14:35

jasonwryan wrote:

You need to narrow down where the disk space is being eaten up:

This is a good idea, but df is not the right tool. Visualize where the space went, i suggest to use ncdu for this.

Also, if you hear that your HDD is active, use iotop to determine which process is writing to it. Instant solution: kill the runaway process

lucak3 · 2011-03-12 09:19:55

check .xsession-errors as it is often the cause for such cases

karol · 2011-03-12 14:06:54

du: cannot access `/home/japtar10101/.gvfs': Permission denied

Run 'du -sh' again, this time as root. Are you using some kind of system trash? Where is it located? From your 'du -sh' listing I don't see where that 60 GB went, so I would look into `/home/japtar10101/.gvfs' or some other funny place (the only trash on my system is '/home/karol/.local/share/Trash' and I have it empty, I don't use gvfs).

Last edited by karol (2011-03-12 14:13:26)

Leonid.I · 2011-03-12 19:55:40

japtar10101 wrote:

75G    /mnt

If /mnt is not a separate mount point, why is it 75G, when / is 68G? I would also remount each filesystem under / with --bind, to see if there are any ghost files there...

Last edited by Leonid.I (2011-03-12 19:58:38)

Leonid.I · 2011-03-12 19:57:54

karol wrote:

du: cannot access `/home/japtar10101/.gvfs': Permission denied
Run 'du -sh' again, this time as root. Are you using some kind of system trash? Where is it located? From your 'du -sh' listing I don't see where that 60 GB went, so I would look into `/home/japtar10101/.gvfs' or some other funny place (the only trash on my system is '/home/karol/.local/share/Trash' and I have it empty, I don't use gvfs).

.gvfs is on a separate filesystem (/home), which is only 15% full...

japtar10101 · 2011-03-13 05:03:55

Huh, my hard drive is back to normal again (I shutdown after the "pacman -Scc"):

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
udev                   10M  212K  9.8M   3% /dev
/dev/sda7              69G  8.1G   58G  13% /
shm                   1.3G  308K  1.3G   1% /dev/shm
/dev/sda5             248M   16M  220M   7% /boot
/dev/sda8              50G  6.3G   41G  14% /home
/dev/sda3              40G   22G   19G  53% /mnt/share
/dev/sda2             130G   55G   76G  43% /mnt/windows

I just remembered I setup yaourt to use powerpill. It's entirely possible powerpill is the problem, rather than yaourt itself. Anyway, I tried running ncdu before and after an update: no significant difference.

$ sudo ncdu -x /
    5.4GiB [##########] /usr                                                                                           
    2.3GiB [####      ] /opt
  123.5MiB [          ] /var
   74.6MiB [          ] /lib
    9.9MiB [          ] /sbin
    7.1MiB [          ] /etc
    5.7MiB [          ] /bin
    3.7MiB [          ] /root
  664.0kiB [          ] /tmp
   20.0kiB [          ] /srv
e  16.0kiB [          ] /lost+found
   12.0kiB [          ] /mnt
    4.0kiB [          ] /lib64
e   4.0kiB [          ] /media
>   0.0  B [          ] /sys
>   0.0  B [          ] /proc
>   0.0  B [          ] /home
>   0.0  B [          ] /dev
>   0.0  B [          ] /boot

Also, where's .xsession-errors located at?

Leonid.I wrote:

japtar10101 wrote:
75G    /mnt
If /mnt is not a separate mount point, why is it 75G, when / is 68G? I would also remount each filesystem under / with --bind, to see if there are any ghost files there...

/mnt is a folder containing several different mount point. No problems there, but good eye nonetheless.

Last edited by japtar10101 (2011-03-13 05:16:21)

Leonid.I · 2011-03-13 19:40:30

japtar10101 wrote:

Leonid.I wrote:
japtar10101 wrote:
75G    /mnt
If /mnt is not a separate mount point, why is it 75G, when / is 68G? I would also remount each filesystem under / with --bind, to see if there are any ghost files there...
/mnt is a folder containing several different mount point. No problems there, but good eye nonetheless.

Oops, I thought that /mtn uses 130G+40G, not 53G+22G=75G... sorry.

Arch Linux

#1 2011-03-12 06:02:46

Running out of Gigs of disk space within seconds

#2 2011-03-12 06:15:08

Re: Running out of Gigs of disk space within seconds

#3 2011-03-12 06:24:58

Re: Running out of Gigs of disk space within seconds

#4 2011-03-12 08:14:35

Re: Running out of Gigs of disk space within seconds

#5 2011-03-12 09:19:55

Re: Running out of Gigs of disk space within seconds

#6 2011-03-12 14:06:54

Re: Running out of Gigs of disk space within seconds

#7 2011-03-12 19:55:40

Re: Running out of Gigs of disk space within seconds

#8 2011-03-12 19:57:54

Re: Running out of Gigs of disk space within seconds

#9 2011-03-13 05:03:55

Re: Running out of Gigs of disk space within seconds

#10 2011-03-13 19:40:30

Re: Running out of Gigs of disk space within seconds

Board footer