From owner-freebsd-stable@FreeBSD.ORG Wed Nov 24 17:18:56 2004 Return-Path: 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 EA7E216A4CE; Wed, 24 Nov 2004 17:18:56 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 690EB43D3F; Wed, 24 Nov 2004 17:18:56 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id iAOHItRo067934; Wed, 24 Nov 2004 11:18:55 -0600 (CST) (envelope-from dan) Date: Wed, 24 Nov 2004 11:18:55 -0600 From: Dan Nelson To: Scott Long Message-ID: <20041124171855.GE95873@dan.emsphone.com> References: <41A4944C.6030808@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A4944C.6030808@freebsd.org> X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: 5-STABLE softupdates issue? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 17:18:57 -0000 In the last episode (Nov 24), Scott Long said: > Matthias Andree wrote: > > out of fun and to investigate claims about alleged bgfsck resource > > hogging (which I could not reproduce) posted to > > news:de.comp.os.unix.bsd, I pressed the reset button on a live > > FreeBSD 5-STABLE system. > > > > Upon reboot, fsck -p complained about an unexpected softupdates > > inconsistency on the / file system and put me into single user > > mode, the manual fsck / then asked me to agree to increasing a link > > count from 21 to 22 (and later to fix the summary, which I consider > > a non-issue). A subsequent fsck -p / ended with no abnormality > > detected. > > No, this in theory should not happen. YOu could have caught it right > at the instance that it was sending a transaction out to disk, or you > could have caught an edge case that isn't understood yet. > Unfortunately, ATA drives also cannot be trusted to flush their > caches when one would expect, so this leaves open a lot of possible > causes for your problem. If you just want to test stability in the face of system crashes (and not power failure), you can drop to DDB and run "reboot" to simulate a panic (or run reboot -qn as root). That way your drive doesn't lose power. That said, I get unexpected softupdates inconsistencies pretty regularly on kernel panics. I just let the system run until I can reboot and run a fsck -p. -- Dan Nelson dnelson@allantgroup.com