0

I'm using Ubuntu Linux 14. I'm running out of disk space

[rails@server ~]$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/simfs       30G   29G  1.5G  96% /

Is there a way to view a more detailed breakdown of what "df" is calculating for each sub-directory? Before I had been using

du -a / | sort -n -r | head -n 15

to find the top directories using space, but then I noticed that "du" is not the same as "df" and in my case, "du" was vastly underreporting how much space was being used ("du" said only 4GB of space was being used)

Dave
  • 2,348
  • 21
  • 54
  • 84
  • 1
    `df` doesn't deal with directories per se. It checks on what each filesystem thinks is its usage via `statvfs` syscall. `du` deals with actual files, it will tell you how much each file is supposed to occupy on disk (unless it's a sparse file). The discrepancy you see is probably due to blocks of data still being claimed on the filesystem (that is there were files, they were unlinked so there's no path to file, but application still keeps that disk space open and in use ). – Sergiy Kolodyazhnyy Nov 09 '19 at 01:35
  • Relating https://unix.stackexchange.com/q/125429/117549 – Jeff Schaller Nov 09 '19 at 01:49
  • @SerglyKolodyazhnyy, maybe I need to open a different question, but how do I identify the blocks of data that are no longer linked to files that is still kept open and more importantly, how do I free those blocks? – Dave Nov 09 '19 at 02:07
  • @JeffSchaller, Maybe I'm missing something but the link you provided references tools that use "du," which doesn't give me accurate readings. Even the top answer, "sudo ncdu -rx /" reports the same numbers that running "du" does. Let me know if I'm misunderstanding something. – Dave Nov 09 '19 at 02:12
  • @Dave There's a few similar questions: https://serverfault.com/q/275206/363611 , https://unix.stackexchange.com/q/45771/85039, https://askubuntu.com/q/280342/295286, https://askubuntu.com/q/256619/295286 In some cases reboots help, in others - `fsck` to fix the filesystem. I'd start with those two. If the issue is lots of open anonymous files ( so `lsof | grep -i deleted` probably ), identify what application opens those files and maybe switch to a different, less aggressive app ( though might not be easy if your business depends on it ) – Sergiy Kolodyazhnyy Nov 09 '19 at 02:30
  • @SerglyKolodyazhnyy, Thanks for these links although both seem to suggest if you stop/restart the process pointing to these removed files, the problem should go away. I've restated my system consecutive times using "sudo reboot now" but the discrepancy remains. – Dave Nov 09 '19 at 04:22

1 Answers1

0

I tried to find out about that sim-filesystem; it has to do with openvz (containers):

simfs is a proxy-filesystem. simfs is not an actual filesystem; it’s a map to a directory on the host (by default /vz/private/).

and:

"Old" simfs fs without quota - is just a bindmount => this is a start point. 1st level quota for simfs-based Containers (the quota for the Container as a whole) can be implemented using project quota which is going to be accepted to mainstream sooner or later.

So you have to identify the physical partition behind that simfs.

  • Thanks for your response but I'm out of my league with Unix and I don't understand how your answer will help me solve my problem. How do I "identify the physical partition behind that simfs" and how do I take that answer to make my disk usage go down? – Dave Nov 09 '19 at 18:23
  • I don't know about this simfs. Here a similar Q: https://unix.stackexchange.com/questions/214448/openvz-disk-used-100 –  Nov 09 '19 at 20:50
  • Hi @rastafile, thx but I'm still not following. You want me to run "vzctl"? – Dave Nov 09 '19 at 23:14
  • Now I "realize" that you have simfs mounted on "/", like in the link. So your "/" is a 30G pseudo-fs. Are you not running in a container? How does that disk space (you are running out) look like? `fdisk -l`? You don't have a `/vz/private` somewhere, outside of `/dev/simfs`? –  Nov 10 '19 at 06:10