From owner-freebsd-stable Mon Mar 17 8:16:32 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 DBED237B401 for ; Mon, 17 Mar 2003 08:16:28 -0800 (PST) Received: from im2.sec.tds.net (im2.mail.tds.net [216.170.230.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C4343F3F for ; Mon, 17 Mar 2003 08:16:27 -0800 (PST) (envelope-from rpclark@tds.net) Received: from x2.trapdoor.org (smga2dsl-a237.ga.tds.net [66.222.52.237]) by im2.sec.tds.net (8.12.8/8.12.3) with SMTP id h2HGGK69010056; Mon, 17 Mar 2003 10:16:20 -0600 (CST) Date: Mon, 17 Mar 2003 11:18:56 -0500 From: Rob Clark To: Peter Jeremy Cc: wkt@minnie.tuhs.org, freebsd-stable@FreeBSD.ORG Subject: Re: Root filling up (((du & df giving different results))) Message-Id: <20030317111856.43fb3722.rpclark@tds.net> In-Reply-To: <20030317094634.GE1200@cirb503493.alcatel.com.au> References: <20030316180013.61be4469.rpclark@tds.net> <20030316233300.GA85862@minnie.tuhs.org> <20030317094634.GE1200@cirb503493.alcatel.com.au> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd4.7) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Greetings, Large file discovered, problem solved. Recently (early February) I installed a second HDD. At first, I had not added the drive to /etc/fstab. At that time I made a back-up iso that was 58MB in size. I'd forgotten that near that time I attempted to write this large file to the new HDD without it being mounted. Once the drive was mounted, the filename was hidden, and once unmounted "Whalah!" there it was. I removed the file and all is good with "/"(root). Thank you everyone who replied, and helped me to isolate this error. Clear Skies, Rob Below is a run down of the file recovery, removal, & results: Commented out 2nd Hdd: # vi /etc/fstab # Device Mountpoint FStype Options Dump ... #/dev/ad1s1e /data ufs rw 2 ... --------------------------------------------------------------------- then: # umount /data --------------------------------------------------------------------- then: # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 128990 105842 12830 89% / /dev/ad0s1f 257998 1188 236172 1% /tmp /dev/ad0s1g 7125722 3699172 2856494 56% /usr /dev/ad0s1e 257998 53898 183462 23% /var procfs --------------------------------------------------------------------- then: # cd /data x2# ls sysbackup-20030209-14:34:13.iso --------------------------------------------------------------------- then: # rm sysbackup-20030209-14:34:13.iso --------------------------------------------------------------------- finally: # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 128990 45954 72718 39% / /dev/ad0s1f 257998 1188 236172 1% /tmp /dev/ad0s1g 7125722 3699172 2856494 56% /usr /dev/ad0s1e 257998 53900 183460 23% /var procfs 4 4 0 100% /proc # mount /dev/ad1s1e /data Much better, again, thanks. On Mon, 17 Mar 2003 20:46:34 +1100 Peter Jeremy wrote: > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message