There are a few tools I use when in this situation: df, du, and mount
du is the most useful for hunting down the culprit that filled up your filesystem:
$du -h --max-depth=1
However at the filesystem root, /
, you won't have permission to access all of the directories to get a read on file sizes, so you'll need sudo
to get full privileges. I just did this on our server at /
and our raid is kinda big, so I bailed on that.
Examples follow:
15:08 chris@server /$ sudo du -h --max-depth=1
8.0K ./mnt
16K ./build
4.1G ./opt
4.0K ./backup
12K ./media
13M ./lib32
38M ./root
300K ./dev
6.0M ./sbin
2.4G ./lib
2.9G ./var
4.0K ./selinux
50M ./home
2.3G ./usr
0 ./proc
7.9M ./bin
5.9M ./tmp
200K ./srv
4.0K ./run
0 ./sys
4.0K ./cdrom
I hit ctrl+c because I'm done waiting on /raid
... So let's see what df says:
15:14 chris@server /$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb7 92G 9.0G 79G 11% /
none 1.9G 300K 1.9G 1% /dev
none 1.9G 0 1.9G 0% /dev/shm
none 1.9G 7.3M 1.9G 1% /var/run
none 1.9G 0 1.9G 0% /var/lock
none 1.9G 0 1.9G 0% /lib/init/rw
/dev/sda1 3.6T 2.3T 1.2T 66% /raid
/dev/sdb9 276M 88M 175M 34% /boot
/dev/sdb8 88G 3.1G 81G 4% /var
Oh, wow, the raid is two-thirds full, maybe it's worth the wait to figure it out?
15:15 chris@server /raid$ !du
du -h --max-depth=1
852M ./www
20K ./investedin
9.8M ./ups
99M ./dealers
3.0G ./photoshoot
69M ./catalog_tech
86G ./misc
4.9G ./marketing
16G ./pics
193G ./Video
37G ./mechanical_design
14M ./tmp
16K ./lost+found
93G ./programs
16K ./.Trash-1000
17G ./Products
1.3G ./vendors
1.1G ./docs
128K ./.Trash-1001
20M ./customers
2.9M ./po_invoices
18M ./_SCANS
Well, it's still hanging out churning, so I'll be patient and let it go in the background. To analyze the above, I look through the sizes of the directories for who the disk hog is. Notice ./programs
is 93G. If that's unexpected, you start drilling down that tree.
I prefer du -h --max-depth=1
because with any more depth, you get a ton of output and in this case, you might just need that one directory where a log has gone crazy (like on a website?)
Edited to add:
And mount
isn't always applicable for your exact case, however, I have used Linux and the above techniques to rescue a Windows install with no free space. mount
can help you see what hard drives are mounted where. Also notice how df
also hints at the output from mount
.
15:25 chris@server ~$ mount
/dev/sdb7 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/dev/sda1 on /raid type ext4 (rw)
/dev/sdb9 on /boot type ext4 (rw)
/dev/sdb8 on /var type ext4 (rw)
What the above tells us is that the first hard drive's first partition (a hardware RAID 5) is on /raid and the actual "hard drive" in the computer is sdb. With /
on sdb7, that reminds me this is the 2nd or 3rd OS I've had on this disk on this server. I put /var
on a separate partition for when logs go crazy.
df -h
in a terminal and post the results?