0

This question already has an answer here:

Somehow, something is eating up around 80GB of HDD space and I cannot figure out what. This is starting to become a major problem for me as I only have 100GB to play with and if I find something to delete, something else will just fill that space, until I can barely use the computer.

I have tried running ncdu -x -q to clear up as much as possible and it says that I am down to about 22G usage. I get the same with du, but I guess ncdu uses du

du -x -d1 -h /
4,0K    /srv
28K     /media
4,0K    /mnt
4,0K    /lib64
16K     /lost+found
3,3G    /home
588M    /opt
360M    /lib
23M     /build
9,7M    /bin
48M     /boot
27M     /etc
1,4G    /root
4,0K    /cdrom
6,9G    /usr
16M     /sbin
9,0G    /var
22G     /

And if I run df:

 df
Filesystem      1K-blocks       Used Available Use% Mounted on
udev              2748080          4   2748076   1% /dev
tmpfs              559400       1568    557832   1% /run
/dev/sdc2       109481872  104180864         0 100% /
none                    4          0         4   0% /sys/fs/cgroup
none                 5120          0      5120   0% /run/lock
none              2796996        688   2796308   1% /run/shm
none               102400          8    102392   1% /run/user
overflow             1024        236       788  24% /tmp
/dev/sdd2      1953382140 1874376664  79005476  96% /media/munhunger/Shaman
/dev/sda1      1953382140 1926088316  27293824  99% /media/munhunger/Holy
/dev/sdb1      2930264060 2930264060         0 100% /media/munhunger/Glory

df -aTh
Filesystem     Type             Size  Used Avail Use% Mounted on
sysfs          sysfs               0     0     0    - /sys
proc           proc                0     0     0    - /proc
udev           devtmpfs         2,7G  4,0K  2,7G   1% /dev
devpts         devpts              0     0     0    - /dev/pts
tmpfs          tmpfs            547M  1,6M  545M   1% /run
/dev/sdc2      ext4             105G  103G     0 100% /
none           tmpfs            4,0K     0  4,0K   0% /sys/fs/cgroup
none           fusectl             0     0     0    - /sys/fs/fuse/connections
none           debugfs             0     0     0    - /sys/kernel/debug
none           securityfs          0     0     0    - /sys/kernel/security
none           tmpfs            5,0M     0  5,0M   0% /run/lock
none           tmpfs            2,7G  688K  2,7G   1% /run/shm
none           tmpfs            100M  8,0K  100M   1% /run/user
none           pstore              0     0     0    - /sys/fs/pstore
overflow       tmpfs            1,0M  236K  788K  24% /tmp
binfmt_misc    binfmt_misc         0     0     0    - /proc/sys/fs/binfmt_misc
systemd        cgroup              0     0     0    - /sys/fs/cgroup/systemd
gvfsd-fuse     fuse.gvfsd-fuse  0,0K  0,0K  0,0K    - /run/user/1000/gvfs
/dev/sdd2      fuseblk          1,9T  1,8T   76G  96% /media/munhunger/Shaman
/dev/sda1      fuseblk          1,9T  1,8T   27G  99% /media/munhunger/Holy
/dev/sdb1      fuseblk          2,8T  2,8T     0 100% /media/munhunger/Glory

Running du with sh flag(and x because I do not want to scan mounted disks)

du -xsh /
22G     /

What could be causing this, and what can I do to mitigate the problem? Running on a linux mint 17 from uname -a: 3.16.0-38-generic #52~14.04.1-Ubuntu

From running lsof | grep -Fw deleted:

lsof | grep -Fw deleted
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.

marked as duplicate by mdpc, Stephen Rauch, Gilles filesystems Aug 3 '17 at 23:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • What OS are you using? – Jesse_b Aug 3 '17 at 19:45
  • Opps, missed the most important part :D It is a linux mint 17 I believe. 3.16.0-38-generic #52~14.04.1-Ubuntu from running uname -a – munHunger Aug 3 '17 at 19:47
  • 2
    I guess this is a huge deleted file (possibly in /var/log) that is still open by a process which keeps writing into it. You would be able to identify it with lsof | grep -Fw deleted. – xhienne Aug 3 '17 at 20:08
  • Can you do df -aTh? – Jesse_b Aug 3 '17 at 20:15
  • community.hpe.com/t5/System-Administration/… . Not pretending I fully understand this but I would still like to see your du -sh / without the x argument. – Jesse_b Aug 3 '17 at 20:26
1

Very similar to Jesse_b's answer, what has worked well for me over the years is simply:

df -xk / | sort -n | tail -40

The -x option to df instructs it not to traverse other mount points. Using -k keeps all the sizes in 1024 byte blocks. The output gets sorted and I tend to like looking at the last 40 lines, but this is purely arbitrary. This should point you to a directory containing the files taking up the most space. If you want files in the output, change the df command to df -axk before piping to sort and tail.

0

You can try this to find where the large file(s) may be but beware this command may be very long running depending on the number of files in your system:

du -k / | sort -nr | head -n25

Here are my results:

[root@JBCLAMP001 ~]# du -x -d1 -h /
512     /boot
512     /system
81M     /var
2.9M    /root
1.0K    /opt
512     /srv
512     /mnt
512     /media
3.0K    /tmp
20M     /home
15M     /etc
5.0K    /native
981M    /usr
1.1G    /

[root@JBCLAMP001 ~]# du -sh /
du: cannot access ‘/proc/45795/task/45795/fd/3’: No such file or directory
du: cannot access ‘/proc/45795/fd/3’: No such file or directory
du: cannot access ‘/native/proc/45795/fd/3’: No such file or directory
du: cannot access ‘/native/proc/45795/path/3’: No such file or directory
8.7G    /
[root@JBCLAMP001 ~]# du -xsh /
1.1G    /

As you can see the du -x -d1 -h / does not find all files.

  • well, sorting is out of the question... no space left on device(and I have a hard time finding anything to delete at this point) – munHunger Aug 3 '17 at 19:50
  • Although, isn't that pretty much the same as running du -x -d1 -h which did not help me find anything? – munHunger Aug 3 '17 at 19:52
  • No, I'm not exactly sure what du -x -d1 -h does but my command will list the 25 largest files in your root file system. – Jesse_b Aug 3 '17 at 19:53
  • As far as I am aware du -x -d1 -h lists the disk usage of all folders in current directory(depth 1) and when I run it on root, there is nothing that takes up full disk storage. i.e. there is 80gb unaccounted for – munHunger Aug 3 '17 at 19:55
  • 1
    Try doing this and see what it finds: du -sh / – Jesse_b Aug 3 '17 at 20:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.