From owner-freebsd-fs@FreeBSD.ORG Mon Mar 19 05:12:33 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 617A116A406; Mon, 19 Mar 2007 05:12:33 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from mgw-ext11.nokia.com (smtp.nokia.com [131.228.20.170]) by mx1.freebsd.org (Postfix) with ESMTP id D4F8013C457; Mon, 19 Mar 2007 05:12:32 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2J5CK0O022634; Mon, 19 Mar 2007 07:12:29 +0200 Received: from siebh102.NOE.Nokia.com ([172.30.195.29]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 07:12:19 +0200 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by siebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 13:12:01 +0800 Received: from [172.30.67.151] ([172.30.67.151]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 16:11:59 +1100 Message-ID: <45FE1BA0.5080609@nokia.com> Date: Mon, 19 Mar 2007 15:12:00 +1000 From: David Cecil User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ext Pawel Jakub Dawidek , freebsd-fs@freebsd.org References: <45F776AE.8090702@nokia.com> <20070314161041.GI7847@garage.freebsd.pl> <45F8EE27.6070208@nokia.com> <20070315090031.GB80993@deviant.kiev.zoral.com.ua> <20070315092659.GA14080@garage.freebsd.pl> <45F9C9B4.4030508@nokia.com> <20070315223641.GA89923@xor.obsecurity.org> <45F9CBCC.7050006@nokia.com> <20070316014846.GA3229@garage.freebsd.pl> <45F9F994.2050803@nokia.com> In-Reply-To: <45F9F994.2050803@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 05:11:59.0279 (UTC) FILETIME=[1F0E0BF0:01C769E5] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070319071230-4CF31BB0-21B9A315/0-0/0-1 X-Nokia-AV: Clean Cc: ext Kris Kennaway Subject: Re: FFS writes to read-only mount 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: Mon, 19 Mar 2007 05:12:33 -0000 >> Could you try disabling bgfsck, by setting background_fsck="NO" to your >> /etc/rc.conf? >> > > Yes, I could do that. Again, I'm reluctant to try the experiment > before getting as much information as possible from ddb. > > From the fsck_ffs man page: > "To be eligible for background cleaning it must have been running with > soft updates, not have been marked as needing a foreground check, and > be mounted and writable when the background check is to be done. If > these conditions are met, then fsck_ffs exits with a zero exit > status. Otherwise it exits with a non-zero exit status. If the file > system is clean, it will exit with a non-zero exit status so that the > clean status of the file system can be verified and reported during > the foreground checks." > > This says the partition must be writable when the check is done. Now > I guess there could be a bug where it's trying to write when it > shouldn't... Maybe I should take a look at the fsck_ffs code too. > >> I know that there is a hack for handling fsck of the root file system. >> Bascially once system is mounted read-only (the partition it resides on >> is opened read-only), it (the partition) can't be opened for write by >> anything else (because of how GEOM works). But there is an exception for >> the root partition, which is opened without exclusive bit at first time, >> which allows, eg. to boot system into single-user mode and run fsck - >> without this hack it won't be possible. So I'm wondering if this can be >> problematic if one use bgfsck for the root file system... >> > > I will look into it some more and report back. > I discovered this morning that the messages were no longer being displayed on the console. I set a breakpoint in sync_vnode and the bufobj corresponding to the problematic buffer is no longer being passed in. I looked back through the history of commands and it appears this was the result of an fsck command I issued. The command that I think stopped it is: # fsck_ffs -B / MOUNTED READ-ONLY, CANNOT RUN IN BACKGROUND ** /dev/mirror/gmroots1f (NO WRITE) ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=165196 OWNER=root MODE=100644 SIZE=0 MTIME=Mar 9 03:55 2007 CLEAR? no Either this is a strange coincidence, or it's somehow caused the buffer to be removed from the list of those to be flushed (or the buffer was flushed?). I tried to determine where the inode corresponding to 165196 is located on disk using fsck. From what I can tell, the inode itself doesn't correspond to the buffer that's causing the problem. The size of this inode is 0, and one inode doesn't correspond well with the ~16k that the syncer is trying to write. Strange... Any thoughts? Thanks, Dave -- Software Engineer Secure and Mobile Connectivity Nokia Enterprise Solutions +61 7 5553 8307 (office) +61 412 728 222 (cell)