From owner-freebsd-fs@FreeBSD.ORG Fri Nov 30 00:28:03 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0076416A417 for ; Fri, 30 Nov 2007 00:28:02 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id A03F513C457 for ; Fri, 30 Nov 2007 00:28:02 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.14.1/8.13.1) with ESMTP id lAU0S0NP036376; Thu, 29 Nov 2007 19:28:00 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.14.1/8.13.1/Submit) id lAU0RtvW036375; Thu, 29 Nov 2007 19:27:55 -0500 (EST) (envelope-from bv) Date: Thu, 29 Nov 2007 19:27:50 -0500 From: Bill Vermillion To: David Cecil Message-ID: <20071130002750.GA36329@wjv.com> References: <474F4E46.8030109@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474F4E46.8030109@nokia.com> User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com Cc: freebsd-fs@freebsd.org Subject: Re: File remove problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 00:28:03 -0000 On Fri, Nov 30, 2007 at 09:41 David Cecil saw "Error reading FAT table? Try SKINNY table?" And promptly said: > Hi, > I've been looking into a problem we're seeing on FreeBSD 6.1, though I > believe the bug will exist in current, or at least 7.0. > Under certain circumstances, when a file is > removed from the filesystem, and the filesystem > is remounted read-only immediately afterwards, > an error such as the following is displayed: > g_vfs_done():mirror/gmroots1f[WRITE(offset=1349058560, > length=16384)]error = 1 > I have determined that the buffer contains an update to the > inode for the file that's deleted. The inode for the directory > change appears to be updated correctly. So what's not making it > to disk is the updated file inode with its changed link counts > (should now be zero). So, somehow this inode is being missed > during the sync prior to the remount completing. > I'm still looking through the code to find the problem, but any > insights from those more familiar with the code would be much > appreciated. Are you sure the sync occured? What happens if you run 'sync' and then perform the above process? Bill -- Bill Vermillion - bv @ wjv . com