From owner-freebsd-stable@FreeBSD.ORG Tue Nov 28 16:49:19 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DE4E16A539 for ; Tue, 28 Nov 2006 16:49:19 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECE1643E5D for ; Tue, 28 Nov 2006 16:46:20 +0000 (GMT) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.8/8.13.8) with ESMTP id kASGjv6q078870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Nov 2006 10:45:57 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <456C67C7.9030208@palisadesys.com> Date: Tue, 28 Nov 2006 10:45:59 -0600 From: Guy Helmer User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Subject: 6.x loosing record of free space after filesystem fills? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2006 16:49:19 -0000 We're encountering some problems on FreeBSD 6.1 SMP with a number of end-user systems where a Postgresql database is growing to the point where the filesystem is nearly full or completely runs out of free space. After this point, df shows wildly incorrect values for available space, sometimes even showing more space available than there allocated to the partition (and our systems rely on df to determine when to send warnings to end-users that the free disk space is getting low). We've found the only way to correct the situation is to take the system down to single-user mode and force a non-background fsck on the partition - simply rebooting the system does not fix the situation. We're going to try setting debug.mpsafevfs to 0 in /boot/loader.conf to see if this works around the problem. I've gone through the CVS logs for src/sys/ufs/ffs/* but I haven't seen anything that would specifically apply to this problem. Has anyone else seen this problem, and by chance is it resolved for 6.2? Thanks, Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc.