1

Weird thing observed

root@noname:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G   12K  3.9G   1% /dev
tmpfs           799M 1020K  798M   1% /run
**/dev/sda1        42G   38G  1.5G  97% /**
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M     0  5.0M   0% /run/lock
none            3.9G   72K  3.9G   1% /run/shm
none            100M   12K  100M   1% /run/user
/dev/sda6       296G  100G  181G  36% /var/lib/noname/jobs

38GBs used on / but cant find where this place is used:

root@noname:/# du -sm *
10  bin
271 boot
1   cdrom
1   dev
19  etc
797 home
0   initrd.img
0   initrd.img.old
1826    lib
1   lib64
1   lic
1   lost+found
1   media
1   mnt
785 opt
0   proc
17  root
2   run
13  sbin
1   srv
0   sys
2   tmp
4843    usr
104366  var
0   vmlinuz
0   vmlinuz.old

Checked if there is a opened and deleted files in use but only some small files there:

root@noname:/# lsof | grep delete
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/112/gvfs
      Output information may be incomplete.
init          1                root   12w      REG                8,1      154    1441810 /var/log/upstart/systemd-logind.log.1 (deleted)
init          1                root   14w      REG                8,1      168    1443848 /var/log/upstart/mountall.log.1 (deleted)
init          1                root   22w      REG                8,1      521    1442332 /var/log/upstart/modemmanager.log.1 (deleted)
init          1                root   25w      REG                8,1      283    1443843 /var/log/upstart/network-manager.log.1 (deleted)
3
  • The numbers don't add up. That is possible if, at one point, device /dev/sda6 was not mounted but data was written to /var/lib/noname/jobs anyway. To check this, unmount /dev/sda6 and do du -sh /var/lib/noname/jobs. If this is huge, you have found your missing data.
    – Jos
    Apr 12, 2017 at 13:39
  • Have you emptied trash & root's trash (which can be difficult?). RecoverLostDiskSpace help.ubuntu.com/community/RecoverLostDiskSpace
    – oldfred
    Apr 12, 2017 at 13:40
  • What's your question? Apr 12, 2017 at 20:32

4 Answers 4

4

Other suggestions here are worth pursuing. Two more possibilities occur to me:

  • You don't say what filesystem you've used. Some (notably Btrfs) can consume a lot of space in hidden data structures. You can recover this space with special filesystem-specific utilities, but you'll need to say what filesystem you're using if you want detailed help.
  • The space might be consumed in a hidden dot-file (or dot-directory) -- that is, a file or directory with a name that begins with .. Such files and directories are hidden by many tools, including du. Thus, your du command omits such files and directories. Ordinarily, you wouldn't have 38 GB consumed in such files or directories, but accidentally renaming something big might do it. I'm not positive, but some file managers might use such directories as their "trash" locations, too, which could account for the space used.
0

Maybe you set up a back up or crash plan and they are taking this space as backups. You should use disk usage analyzer to scan the said directory and find where all the space is going. But most likely it also won't show this space unless you start it with sudo.

0

Run gksudo baobab to launch a graphical disk usage analyzer, that should help you find the junk.

0

Try using:

du -csh /*

That is supposed to show a summary of the disk space of each directory in the / (root). You can go from there in the biggest folders (usually tmp and var but it may vary).

If inside a folder for example /var you can use like that:

du -csh ./*

That will show for all folders within the directory you are.

Not the answer you're looking for? Browse other questions tagged .