Date: Mon, 19 Mar 2007 15:12:00 +1000 From: David Cecil <david.cecil@nokia.com> To: ext Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-fs@freebsd.org Cc: ext Kris Kennaway <kris@obsecurity.org> Subject: Re: FFS writes to read-only mount Message-ID: <45FE1BA0.5080609@nokia.com> In-Reply-To: <45F9F994.2050803@nokia.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45FE1BA0.5080609>