What's taking up all my disk space?
matthew at freebsd.org
Tue Jan 26 11:16:25 UTC 2016
On 01/26/16 10:39, Polytropon wrote:
> On Tue, 26 Jan 2016 11:21:25 +0100, Murk Fletcher wrote:
>> Woke up to a nasty surprise this morning:
>> /: write failed, filesystem is full
>> # df -h
>> Filesystem Size Used Avail Capacity Mounted on
>> /dev/gpt/rootfs 38G 35G -7.4M 100% /
>> devfs 1.0K 1.0K 0B 100% /dev
>> fdescfs 1.0K 1.0K 0B 100% /dev/fd
>> linprocfs 4.0K 4.0K 0B 100% /usr/compat/linux/proc
>> I have no idea why this is because I'm only using my FreeBSD VPS to run a
>> small Rails app in `/usr/home/`:
>> # du -sh /usr/home
>> 8.6G /usr/home
>> # du -sh /usr/
>> 12G /usr/
>> # du -sh /
>> 34G /
>> Maybe there's a way to use `du` to show all files larger than 1GB and then
>> pass it on to some other command to sort them by size?
> First determine which top-level directory entry is abnormally
> # du -hs /*
> Then narrow down the problem. I suspect /var or /tmp...
Another good trick is to find large files that have been modified recently:
find / -xdev -type f -mtime -1 -size +10M -ls
will show you all the files greater than 10MiB modified within the last
day on the root partition.
Your du(1) and df(1) outputs are in pretty good agreement as to the
amount of space used, so you probably aren't suffering from the effects
of a process holding an open file descriptor on a file that has been
deleted from the filesystem. That still uses disk space, which shows up
in the df(1) results, but because it's a file without a filname
associated with it, du(1) wouldn't be able to count it. That's something
you can frequently get if you use newsyslog to cycle log files but don't
signal the right process to re-open all its logfiles.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the freebsd-questions