James wrote:
> Mark Knecht gmail.com> writes:
>
>
>
>>OK, good info - but what can I remove? Or more important how can I
>>find what's talking up too much space. /home, /usr/portage and /var
>>are on partitions of their own. There is about 200MB of Java stuff in
>>/opt and I deleted everything in /tmp before I wrote the first note.
The first question to ask is "Did it fill up slowly or has it filled up
fairly quickly?" If it was quick, chances are a runaway process did
something, like write a big coredump, a log which filled up due to
errors, a file copy that didn't fit, stuff like that.
Now you mention that the most likely point for that trouble are
accounted for (/tmp, /var). You also mention you use MythTV over the
network. So I would look at the (NFS?) mountpoint first; it happened to
me that the share wasn't mounted, and mythtv then happily fills up the
partition on which the mountpoint resides, ie. /.
So run a 'du -s' on /mnt/* (if that is your mountpoint) after unmounting
all network shares (a mounted dir can hide a file!).
Next, run du -s on the files and dirs in /root/. Maybe logging or cache
was written there (don't forget the dot-entries!)
Also, look into /usr/src and remove sources you can miss.
If nothing helps there, you best run a 'du -s /*' but you better umount
everything that isn't essential first. And even then, it's slw...
In the case it filled up slowly you are worse off. You then know you
have to remove stuff you may need instead of just finding 'the culprit'.
Look carefully into the entire tree and decide what you need and what
you can do without. Likely candidates are Howtos and such, but they
reside under /usr/share so it's likely they aren't on your / filesystem.
They are small, too, so you don't gain that much.
One you have space, you can gain much more by gzipping stuff (especially
mysqldumps, logs, etc) but as you stated /var is on it's own partition I
fear there will not be much to gzip anyway...
One last remark: It happened to me on occasion that a filesystem keeps
at 100% full until you reboot the box. It may be that a process still
has files open, or that an fsck is in order, or whatever. This is the
reason you should never let / fill up; it doesn't always recover very
gracefully, at least that has been my experience. I still have to guess
at the exact reason that stays-at-100% happens, if anyone can explain...
Good luck,
Maarten
>
> Well the first thing you need to do, is run a 'df' and see which
> partitions are full. Then used these tools to find files by size and
> date. Let's assume we're talking about /usr/portage/distfiles
>
> for example:
>
> REMOVING LARGE FILES IN /usr/portage/distfiles
> find ./ -size +10 -exec ls -lag {} \; | less
> find ./ -size +10 -print -exec rm {} \;
>
>
> You can then changethe size and work your way down.
>
> Now let's look at old files in /usr/portage/disfiles
>
> REMOVING OLD FILES IN /usr/protage/distfiles
> find ./ -mtime +180 -exec ls -lag {} \; | less
> find ./ -mtime +180 -print -exec rm {} \;
>
>
> It really helps if you do this a the 90% point, and avoid
> sluggish behavior.
>
> Look at /home too. If you have one big partition, as recommended
> in the handbook then removing any files will help.
>
> /usr/src/* is another place to remove kernel sources, similarly,
> /boot/
>
> Be cautions!
>
> hth,
> James
>
--
gentoo-user@gentoo.org mailing list
