From owner-freebsd-stable Mon Mar 17 1:46:45 2003 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C57E037B404 for ; Mon, 17 Mar 2003 01:46:43 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99FAE43F85 for ; Mon, 17 Mar 2003 01:46:42 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.8/8.12.8) with ESMTP id h2H9kfM2001338; Mon, 17 Mar 2003 20:46:41 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h2H9kYnC001337; Mon, 17 Mar 2003 20:46:34 +1100 (EST) Date: Mon, 17 Mar 2003 20:46:34 +1100 From: Peter Jeremy To: Rob Clark , Warren Toomey Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Root filling up (((du & df giving different results))) Message-ID: <20030317094634.GE1200@cirb503493.alcatel.com.au> References: <20030316180013.61be4469.rpclark@tds.net> <20030316233300.GA85862@minnie.tuhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030316233300.GA85862@minnie.tuhs.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 17, 2003 at 09:33:00AM +1000, Warren Toomey wrote: >On Sun, Mar 16, 2003 at 06:00:13PM -0500, Rob Clark wrote: >> i.e., >> # du -kx / | sort -nr | head -20 >> 45959 / >> ... >> >> # df >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> /dev/ad0s1a 128990 105842 12830 89% / > >I can think of two issues here. > >1. du adds up the file sizes and gives you a result in 1K units. But, > each file actually takes up an integral number of fragments. If your > / fragment size is, say 4K, and you have a whole heap of small files, > then du will report a total size which is much less than df. I'm not sure about this one. du accumulates {stat(2)}.st_blocks which is described as the actual number of 512-byte blocks allocated to a file. >2. You have a process running that has an open file descriptor to a file > on / which has been unlinked (e.g rm'd). The process is still using > the file, but the name no longer exists, and so du or ls won't show it. > To test this, reboot the system and see if the disk space goes up. This is fairly common. ports/sysutils/lsof can tell you if there are unlinked files open (by the missing name). Some system utilities create files in /tmp and then unlink them while they're open for security. I can think of a few others: 3. You have a lot of file (actually filesystem block) allocation and freeing on a soft-updates system. It takes softupates 30-60 seconds to return freed blocks back to the free list. If there's a lot of file creation/deletion you can quickly run out of space. 4. You've mounted a filesystem over a non-empty directory. Eg you were using /tmp in single-user mode and forgot to empty it before going to multi-user mode with /tmp on a different filesystem. My bet is 2 or 3. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message