Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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?

share|improve this question
    
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
add comment

marked as duplicate by Eliah Kagan, qbi, hhlp, Tom Brossman, Stephen Myall Jan 19 '13 at 12:15

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

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.

share|improve this answer
    
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
add comment

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 /
share|improve this answer
    
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
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.