2

Possible Duplicate:
What is taking up so much space on my disk, beside the filesystem?

I have a storage drive (2TB) and an OS drive (90GB SSD). I've run out of space on the OS drive:

/$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        72G   72G     0 100% /
udev            5.9G   12K  5.9G   1% /dev
tmpfs           2.4G  1.2M  2.4G   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            5.9G  428K  5.9G   1% /run/shm
/dev/sda1       1.9T  639G  1.2T  37% /media/StorageDrive

So be it. But when I attempt to figure out where the space has gone, I cannot find it anything remotely approaching the capacity of the drive:

/$ sudo du -h -d 1
du: cannot access `./media/StorageDrive/home/ari/.gvfs': Permission denied
675G    ./media
2.3G    ./var
0   ./proc
7.0M    ./tmp
27M ./boot
4.0K    ./lib64
12K ./dev
44M ./home
16K ./lost+found
8.0M    ./sbin
223M    ./lib
4.0K    ./selinux
1.4M    ./run
140K    ./root
8.8M    ./bin
4.0K    ./mnt
38M ./etc
8.0K    ./srv
4.8G    ./usr
65M ./opt
0   ./sys
682G    .

Note the difference between the total (682G) and the mounted drives in /media (675G) is only about 9G. How are 72G being used? Where is this dark matter hiding?

Community
  • 1
Ari B. Friedman
  • 394
  • 1
  • 4
  • 21
  • Can't you use Baobab disk usage analyser to analyse it? – Danial Behzadi Nov 30 '12 at 17:13
  • @DanialBehzadi Not sure why that would see any files that `du` is missing. Indeed, it shows the same thing as `du`: there's no directory on `/` other than `/media` big enough to come close to filling the drive. – Ari B. Friedman Nov 30 '12 at 17:30

2 Answers2

2

If it's not a subdirectory causing problems, it's possible that there is a large file in / taking up space. Please run the following to see if there's a likely culprit there:

sudo ls -al /
ImaginaryRobots
  • 9,058
  • 4
  • 34
  • 38
  • Good thought, but `sudo ls -al /` shows the largest file as `tmp` at 118784 bytes, then `etc` at 12288 bytes, then the rest all directories at 4096 bytes. Odd that `tmp` and `etc` which are both directories aren't also 4096. `lost+found` is 16384 bytes. – Ari B. Friedman Nov 30 '12 at 17:26
2

I've found the answer, and unfortunately it's too localized to help anyone. When I hooked my backup drive up to backup, it didn't mount it to the usual spot for some reason. So a directory BackupDrive was created in /media (and thus on /dev/sdb1), which had filled up. Epic fail.

Ari B. Friedman
  • 394
  • 1
  • 4
  • 21
  • lol - but hey, people will know not to make the same mistake! – WindowsEscapist Nov 30 '12 at 17:37
  • @WindowsEscapist Ha, true. But now I have to re-do my backup! – Ari B. Friedman Nov 30 '12 at 17:44
  • I'm confused. You mounted an external disk under `/media/xxx`. That shouldn't have affected the output of `df -h /dev/sdb1`, though. `df` only looks at one filesystem at a time, and it ignores where partitions have been mounted. – Flimm Nov 30 '12 at 17:57
  • "BackupDrive" versus "StorageDrive"? – ImaginaryRobots Nov 30 '12 at 18:26
  • `df` was speaking true, as was `du`. `du` showed me the usage for `/media` though, which I assumed was all `storagedrive` because the backup drive was unmounted. In fact, though, it was `storagedrive` (mounted) plus a directory `backupdrive` (which was where the actual backup drive was supposed to get mounted, but hadn't been when the backup was made). – Ari B. Friedman Nov 30 '12 at 21:28