2

I have a small Intel NUC with a 30GB drive. My problem is that this drive is full but cannot find the cause of it.

df reporting the following

Filesystem     1K-blocks      Used Available Use% Mounted on
udev              899412         0    899412   0% /dev
tmpfs             189284      2676    186608   2% /run
/dev/sda2       28414508  27751116         0 100% /
tmpfs             946404         0    946404   0% /dev/shm
tmpfs               5120         4      5116   1% /run/lock
tmpfs             946404         0    946404   0% /sys/fs/cgroup
/dev/loop0           128       128         0 100% /snap/bare/5
/dev/loop1         56832     56832         0 100% /snap/core18/2128
/dev/loop2         56832     56832         0 100% /snap/core18/2246
tmpfs             946404         0    946404   0% /tmp
/dev/loop3        314880    314880         0 100% /snap/makemkv/381
/dev/loop4         66688     66688         0 100% /snap/gtk-common-themes/1515
/dev/loop5         63360     63360         0 100% /snap/core20/1169
/dev/loop6         63360     63360         0 100% /snap/core20/1081
/dev/loop7         33280     33280         0 100% /snap/snapd/13270
/dev/loop8        317184    317184         0 100% /snap/makemkv/385
/dev/loop9         33280     33280         0 100% /snap/snapd/13640
/dev/loop10        66816     66816         0 100% /snap/gtk-common-themes/1519
/dev/sda1         306584      5356    301228   2% /boot/efi
tmpfs             189280         4    189276   1% /run/user/1000

Computing this it gives somewhere around ~14GB of used disk space.

Running sudo lsof | grep REG | grep -v "stat: No such file or directory" | grep -v DEL | awk '{if ($NF=="(deleted)") {x=3;y=1} else {x=2;y=0}; {print $(NF-x) " " $(NF-y) } }' | sort -n -u | numfmt --field=1 --to=iec | tail -10

gives me a list with few processes that matters:

5,5M  /usr/lib/php/20190902/fileinfo.so
6,8M  /usr/lib/jellyfin/bin/libcoreclr.so
8,0M  /var/log/journal/6296b00d07874d0a9533eed0efb81840/user-1000.journal
8,2M  /usr/lib/jellyfin/bin/System.Private.Xml.dll
8,3M  /usr/lib/locale/locale-archive
8,9M  /usr/lib/jellyfin/bin/System.Private.CoreLib.dll
10M  /usr/lib/udev/hwdb.bin
24M  /snap/snapd/13640/usr/lib/snapd/snapd
27M  /usr/lib/x86_64-linux-gnu/libicudata.so.66.1
64M  /memfd:pulseaudio

Running sudo du -sh / --exclude=disks --total gives me a total of 13GB.

So, basically I am out of ideas on how to find out were are the missing ~16GB that the system reports as being somewhere filling out my drive.

An the report is actually behave as such, running

cd ~/ && touch example && echo "FooBar" > example
-bash: echo: write error: No space left on device

Thank you in advance, and, any ideea is a good ideea, basically a have a device that at the current moment is unusable and my options are running low (basically a clean reinstall / buy a larger ssd for a device that should not use more than 20gb)

AdminBee
  • 22,803
Adrian Tilita
  • 31
  • 1
  • 4
  • hello, welcome to unix.se. You should have a look at the answer here : https://unix.stackexchange.com/a/68532/27616 ( few things to try, starting with lsof -nP +L1 and various variant (linux and not linux)) – Olivier Dulac Oct 29 '21 at 12:28
  • Thank you, but, unfortunately lsof -nP +L1 does not give me anything relevant :( - the solutions on that page takes me to 2 usages - journal and pulseuadio, both having a size measured in MB - nothing pops up for GB level usages :( – Adrian Tilita Oct 29 '21 at 12:49
  • maybe check if you don't have "zillions" of small files : each file takes a ("small") amount of disk (usually because it occupies at least an inode, which size varies depending on the file size and the filesystem). it can add up... and "df" will show the disk space occupied (full inode space coounted), whereas "du" will show the added file sizes (just the cotent of the files, not the space the inode containing this data occupies). – Olivier Dulac Oct 29 '21 at 13:28
  • another possibility: it could lie "underneath" a mounted filesystem (/tmp ? for exemple) You can, in linux, remount "/" (using a free loop device) as read-only somewhere (say: /mnt/readonlyroot/), and browse that using du -hs /mnt/readonlyroot, and compare to du -hxs / # -x prevents du to descend to another filesystem mounted underneath "/", such as "/tmp") – Olivier Dulac Oct 29 '21 at 13:36
  • (and I don"t understand "Computing this it gives somewhere around ~14GB of used disk space." : the df you show shows 27gb in /, not 14. you maybe compared it to a "du -hxs /" output, that amounts to 14gb?) – Olivier Dulac Oct 29 '21 at 13:39
  • I put all this in an answer, as it could help others... But you can still answer here to the various possibilities (and my question on the "amount to 14gb" part) – Olivier Dulac Oct 29 '21 at 14:00
  • Bad choice of position that statement - I calculated all that du gave me and round it up to 14GB :| sorry for the confussion – Adrian Tilita Oct 29 '21 at 19:47
  • Here's a command I recommend you run from the / folder to track all top-level folders by disk usage: du -xhad1 | sort -h. If the total it reports is short of your root disk size, then what remains is likely deleted files that still have open file handles and you would need to follow one of the other suggestions about using lsof to track it down. – penguin359 Oct 29 '21 at 21:48

1 Answers1

6

Some possibilities to try to find the thing filling your "/" partition:

  • lsof -nP +L1 # should list all files that were deleted (unlinked) but are still opened by a process and therefor still occupy the dist
  • See also that answer: https://unix.stackexchange.com/a/68532/27616 which gives a few additionnal informations and things to try
  • Another possibility: check (with df -ih / ) if you don't have "millions" of small files in that / filesystem : each file takes at least a "small" amount of disk (usually because it occupies at least 1 inode, which size varies depending on the file size and the filesystem). This can add up... if the minimum disk space occupied is 512bytes, having 1 million files of 1 byte each will still occypy 512 million bytes instead of 1 million bytes. df will show the disk space occupied (full inode space coounted), whereas du will show the added file sizes (ie, just the content of those files, not the space that the inode(s) containing this content occupies)
  • Another possibility: there could be some big file(s) hidden by a mounted filesystem. Ie, some files could lie "underneath" a mounted filesystem (maybe you put a lof of big files in the /tmp directory (the one that is in the / filesystem, and which is then used as a mount point to mount the /tmp filesystem) ? This could happen if you put things in there while the /tmp filesystem was not mounted. To check this, you can, in linux, remount / (using a free loop device) as read-only somewhere (say: mount it underneath a /mnt/readonlyroot/ mount point), and browse that using du -hs /mnt/readonlyroot, and compare to du -hxs / # -x prevents du to descend to another filesystem mounted underneath /, such as the /tmp filesystem for exemple).
    • command to mount (a 2nd time) / as readonly underneath some mount point: you can (from the top of my memory... I can't check that on linux right now) :
      • mkdir -p /mnt/rootreadonly/ to create the directory mount point (which will be, ironically, inside the "/" filesystem...)
      • mount -o loop -o ro /dev/sda2 /mnt/rootreadonly (to make that "/" filesystem appear there as read-only. I specify sda2 here as you show your "/" filesystem is in "/dev/sda2" in your question. Some other person reading this answer should first check the output of mount to see where their / filesystem come from...)
  • Thank you for all your support. For the first point (lsof) I have 3 files (0 size). du -ih gave me 302K. The /tmp is rather "ligth" in size - BUT - I am having difficulties following your narative for this lead (my fault - I am not great with the linux ecosystem) so will try to read it very careful before excluding this part. – Adrian Tilita Oct 29 '21 at 19:54
  • 1
    Pointing me in the direction of mounted directories, I did found an anomaly of about 17GB. I have a mounted drive in disks directory UUID="5C9CE0249CDFF68C" /disks/w1 ntfs-3g rw,user,exec,uid=media,gid=media 0 0 - apparently my ssystem created a new directory /disks/w1a where it stored the missing disk space. Can't figure out why it created a new directory /disks/w1a/disks/w1/ but I guess is enough for me to restore my device. Thank you Oliver, if we ever meet, beer is on me :) – Adrian Tilita Oct 29 '21 at 20:00
  • @AdrianTilita glad I could help :) I would be glad to go for that beer and chat about computer related shenanigans... but it may be difficult to meet : I live in France ^^ (your profile doesn't show your location either). – Olivier Dulac Nov 02 '21 at 13:07