From owner-freebsd-fs@FreeBSD.ORG Fri Nov 30 00:50:09 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 AACF716A417 for ; Fri, 30 Nov 2007 00:50:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 89D0513C459 for ; Fri, 30 Nov 2007 00:50:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 29 Nov 2007 16:37:34 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 84B08126B57; Thu, 29 Nov 2007 16:37:33 -0800 (PST) Message-ID: <474F5B4B.5070502@elischer.org> Date: Thu, 29 Nov 2007 16:37:31 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: bv@wjv.com References: <474F4E46.8030109@nokia.com> <20071130002750.GA36329@wjv.com> In-Reply-To: <20071130002750.GA36329@wjv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: File remove problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 00:50:09 -0000 Bill Vermillion wrote: > 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 occurred? What happens if you run 'sync' > and then perform the above process? Kirk said that soft updates can take up to 3 syncs for the dependencies to flush through.. I don't know if that is relevant. One would think the making it read-only would call the same code as unmount to make sure everything was flushed through.. > > Bill > >