From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1F9RBi-0003DM-Rz for garchives@archives.gentoo.org; Wed, 15 Feb 2006 18:15:39 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1FIE1if010892; Wed, 15 Feb 2006 18:14:01 GMT Received: from dns.ultratux.net (ultratux.xs4all.nl [80.126.98.237]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1FI96dh022293 for ; Wed, 15 Feb 2006 18:09:06 GMT Received: from morpheus.kijkduin ([10.42.42.142]) by dns.ultratux.net with esmtp (Exim 3.36 #1 (Debian)) id 1F9R5N-0000qU-00 for ; Wed, 15 Feb 2006 19:09:05 +0100 Message-ID: <43F36E41.40801@ultratux.org> Date: Wed, 15 Feb 2006 19:09:05 +0100 From: Maarten User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050824) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: File system full issues References: <5bdc1c8b0602150323s34875e65m2876d76e6039337@mail.gmail.com> <200602151141.21630.mike@gaima.co.uk> <5bdc1c8b0602150442r34d9c943medde2bc25e543c54@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: df1e9163-c304-4b0b-957e-4be7b7345f7d X-Archives-Hash: 646d555dbf063edc82a57dd1c1227af8 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 sloooow... 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 +100000 -exec ls -lag {} \; | less > find ./ -size +100000 -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