From owner-freebsd-stable Tue Jul 14 10:05:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA04147 for freebsd-stable-outgoing; Tue, 14 Jul 1998 10:05:30 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from destiny.erols.com (root@destiny.erols.com [207.96.73.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA04140 for ; Tue, 14 Jul 1998 10:05:25 -0700 (PDT) (envelope-from jdowdal@destiny.erols.com) Received: from destiny.erols.com (someone@destiny.erols.com [207.96.73.65]) by destiny.erols.com (8.8.8/8.6.12) with SMTP id NAA06025; Tue, 14 Jul 1998 13:04:30 -0400 (EDT) Date: Tue, 14 Jul 1998 13:04:29 -0400 (EDT) From: John Dowdal To: Jonathan Smith cc: Nino Tungul , freebsd-stable@FreeBSD.ORG Subject: Re: Full file system In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 10 Jul 1998, Jonathan Smith wrote: > > Help! Help! Help! > > > > I'm new with freeBSD and I always get a message > > "kernel: uid 0 /: file system full" on our server, but when run df it only > > shows 41% (mounted on / ) on capacity. How can I clear this mess.? > > Can somebody help me? > > > / must also contain /temp. Some programs create temporary files that are > 'unlinked' and 'open' so the file is accessible from the prog where it is > open, but appears to not exist. > >From my experience, 'df' includes files which are in the unlinked but open state in its usage statistics. These files will make the number returned by 'du -skx /' not equal to the number returned by 'df -k /'. > I'd reccomend putting /tmp as it's own partition. Recommendation stands. Possible accurate explainations: 1) Assume no unlinked but open files Process owning the files which fail to write because of disk full closes and delete the files, freeing the space. This may cause the program to abnormally terminate or produce truncated results. It may also reduce in reduced functionality, such as 'vi' not being able to recover files or undelete large blocks which were deleted 2) Assume unlinked but open files fill the disk Process owning the files which fail to write will abnormally terminate, causing the space to be freed because all open files are closed on termination. Check for terminated daemons and abnormal terminations in your logs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message