From owner-freebsd-questions Mon May 17 12:33:33 1999 Delivered-To: freebsd-questions@freebsd.org Received: from hera.webcom.com (hera.webcom.com [209.1.28.42]) by hub.freebsd.org (Postfix) with ESMTP id 8A39614CD0 for ; Mon, 17 May 1999 12:33:27 -0700 (PDT) (envelope-from graeme@echidna.com) Received: from kigal.webcom.com (kigal.webcom.com [209.1.28.57]) by hera.webcom.com (8.9.1/8.9.1) with SMTP id MAA09203; Mon, 17 May 1999 12:33:27 -0700 Received: from [204.143.69.35] by inanna.webcom.com (WebCom SMTP 1.2.1) with SMTP id 27831662; Mon May 17 12:29 PDT 1999 Message-Id: <3740992B.66E9@echidna.com> Date: Mon, 17 May 1999 15:33:15 -0700 From: Graeme Tait Organization: Echidna X-Mailer: Mozilla 2.02 (Win16; I) Mime-Version: 1.0 To: cjclark@home.com Cc: freebsd-questions@freebsd.org, info@boatbooks.com Subject: Re: Lost file space References: <199905171909.PAA29513@cc942873-a.ewndsr1.nj.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Crist J. Clark wrote: > > [You should really try for < 80 column lines.] Sorry about that - I was trying to fit the df output on one line, and overshot a bit. Rather than make a total shambles of the quoted part, I'll leave it as is. Also, I apparently didn't make myself clear. Although df says 337MB are available, in fact almost nothing is available at this point. A few more MB and the filesystem is declared full. Normally, df shows 100% when a filesystem is filled by a regular user, and it can go to about 109% if filled with root privileges, since root can use the slack space. In this particular case, even as root, I can't fill the /usr/www filesystem beyond 90% as indicated by df, or about the point where 330MB is indicated as "Avail". I seem to remember someone posting recently about files that are marked deleted but still have residual links - if I'm understanding correctly. Could that be what's happening? > Graeme Tait wrote, > > Recently I noticed that the filesystem listed below is reported "full" while only at 90% > > capacity (for the df -ik report below, it's almost at "full"). This did not used to be > > the case AFAIK. > > > > FWIW, this filesystem was built with 'newfs -f 512 -b 4096 -i 2048', and is mounted > > 'async local noatime'. In routine operation, there is very little write activity to this > > filesystem. > > > > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on > > > > /dev/da1s1f 3563104 2941142 336913 90% 908255 733055 55% /usr/www > > > > > > There were a couple of power failures (faulty UPS, wouldn't you know!) and automatic > > reboots at the colo 20 days ago. I can't say for sure if the problem arose then or > > later, but I suspect it was later. I'm assuming since the system rebooted OK that the > > filesystems were clean after the fsck. > > That looks exactly right to me, > > (3563104 - 2941142 - 336913)/3563104 = 0.0800 > > The operating system reserves a certain amount of space (8% by > default) because the filesystem performs _much_ better with some free > space available. Performance plumets precipitously after about > 10%. However, privileged users may access this extra space. You can > easily fill a fs to 108% when a root owned process goes a little nuts. > > To summarize, nothing is broken on your system. > > The 8% default can be changed in tunefs(8). -- Graeme Tait - Echidna To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message