From owner-freebsd-fs@FreeBSD.ORG Fri Nov 30 00:01:35 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 509D016A418 for ; Fri, 30 Nov 2007 00:01:35 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.freebsd.org (Postfix) with ESMTP id 01EDC13C467 for ; Fri, 30 Nov 2007 00:01:34 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lATNfsal002010 for ; Thu, 29 Nov 2007 17:42:18 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 01:42:02 +0200 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 01:42:01 +0200 Received: from [172.30.67.20] ([172.30.67.20]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 10:41:59 +1100 Message-ID: <474F4E46.8030109@nokia.com> Date: Fri, 30 Nov 2007 09:41:58 +1000 From: David Cecil User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2007 23:42:00.0008 (UTC) FILETIME=[6F850C80:01C832E1] X-Nokia-AV: Clean Subject: 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:01:35 -0000 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. Thanks, Dave