Score:1

Unable to find what's taking up so much space

cn flag

I'm having an issue in trying to figure out what's taking up so much space on one of my drives, specifically /dev/sdc1 which is mounted on /

As you can see below 862G are in use, I've used all methods I could think of to find the largest directories (excluding sdb1 and sda1) and all I can find is 19G on my Plex metadata folder. That's it... I need to figure out a way to find what exactly is taking up this amount of space as this just happened in the last couple of days after sdb1 was unmounted due to a power outage, so it somehow "linked" or transferred files over there? Though I can't seem to find any... and have absolutely no idea how to go from here...

I'm running Ubuntu 20.04.3 LTS on a headless Odroid N2+

Filesystem      Size  Used Avail Use% Mounted on
udev            1.4G     0  1.4G   0% /dev
tmpfs           370M  6.3M  364M   2% /run
/dev/sdc1       938G  862G   29G  97% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           1.9G  4.0K  1.9G   1% /tmp
/dev/mmcblk1p1   29G   10G   18G  37% /media/mmcboot
/dev/sdb1       1.8T  1.6T  108G  94% /mnt/hdd2
/dev/sda1       7.3T  6.8T  504G  94% /mnt/hdd
/dev/zram1       49M  4.6M   41M  11% /var/log
tmpfs           370M     0  370M   0% /run/user/1000

Results of my search using

sudo du -hs .[^.]* | sort -rh | head -30

19G     .config
12M     .docker
56K     .bash_history
4.0K    .viminfo
4.0K    .profile
4.0K    .cache
4.0K    .bashrc
4.0K    .bash_logout
0       .Xauthority
0       .sudo_as_admin_successful

I tried ncdu as well and it shows:

   19.0 GiB [##########] /.config                                                                                                                                                      11.5 MiB [          ] /.docker
   56.0 KiB [          ]  .bash_history
e   4.0 KiB [          ] /Downloads
    4.0 KiB [          ] /.cache
    4.0 KiB [          ]  .bashrc
    4.0 KiB [          ]  .viminfo
    4.0 KiB [          ]  .profile
    4.0 KiB [          ]  .bash_logout
    0.0   B [          ]  .sudo_as_admin_successful
    0.0   B [          ]  .Xauthority

using sudo du -xh -d 3 / | sort -h -r | egrep -v '*K|*M'

yields

109G    /
84G     /mnt/downloads
84G     /mnt
83G     /mnt/downloads/nzbget
19G     /home/sptz/.config
19G     /home/sptz
19G     /home
4.5G    /var
4.3G    /var/lib
4.1G    /var/lib/docker
1.5G    /usr

I'm guessing the above is excluding /mnt/hdd and /mnt/hdd2 aka sdb1 and sda1 right?

Any ideas?

Thanks!

uz flag
Jos
Suppose one file system (say `/dev/sdb1`) should be mounted on `/dev/sdc1`, with mount point `/mnt/hdd`. Suppose, however, that the mount has failed. If some process still writes data to `/mnt/hdd`, it will end up on `/dev/sdc1`. If you subsequently mount `/dev/sdb1` successfully, this data is not accessible (because `/mnt/hdd` now points to the other filesystem) but it still takes up space. Could this be what has happened in your case?
N0rbert avatar
zw flag
Mount this disk from other system and run `ncdu` on it.
Sptz87 avatar
cn flag
Jos, I believe this is exactly what happened. No idea how to fix it now :/
walttheboss avatar
es flag
Please edit your question by adding what distribution you are on. For example Ubuntu 20.04
Score:1
vn flag

You said it yourself: "sdb1 was unmounted due to a power outage". This probably means that in this time, some data was written to /mnt/hdd2 while sdb1 wasn't mounted.

Unmount these devices:

/dev/sdb1       1.8T  1.6T  108G  94% /mnt/hdd2
/dev/sda1       7.3T  6.8T  504G  94% /mnt/hdd

And then check the directories for data (starting with /mnt/hdd2) - I believe there will be around ~750 GB of data here.

My guess is that data was written to one of these directories, where the disk wasn't mounted. This data now "disappears" when the drives are remounted.

This is only a qualified guess, but 99% of the time when data mysteriously disappears, this seems to be the issue.

Sptz87 avatar
cn flag
This was it! I unmounted both those devices and there it was. 700GB of data in mnt/hdd. I get the logic behind it but does this mean that if sda1 was mounted it's literally impossible to access those "hidden" files?
Artur Meinild avatar
vn flag
Yes. (-----------)
HuHa avatar
es flag
@Sptz87: There is a way, but it's not for the faint of heart: https://github.com/shundhammer/qdirstat/blob/master/doc/Shadowed-by-Mount.md
Artur Meinild avatar
vn flag
Yes, I believe a simple unmount, investigation and remount should be sufficient in most cases.
Score:0
es flag

Install qdirstat Run it as root by launching it from the Terminal/Konsole.

sudo qdirstat

Choose the root or home directory and then run it. It will find where the stuff is.

Sptz87 avatar
cn flag
Unfortunately that's a graphical software. My server is headless and have no way of connecting a monitor to it :/ There has to be an alternative
cn flag
@Sptz87 not totally true, You can use it command linen and if you add this https://github.com/shundhammer/qdirstat/tree/master/scripts you can use cron to do it every so often too
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.