Date: Tue, 20 Mar 2007 16:58:15 +1000 From: David Cecil <david.cecil@nokia.com> To: ext Pawel Jakub Dawidek <pjd@freebsd.org>, ext Kris Kennaway <kris@obsecurity.org> Cc: freebsd-fs@freebsd.org Subject: Re: FFS writes to read-only mount Message-ID: <45FF8607.8060501@nokia.com> In-Reply-To: <45FE1BA0.5080609@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> <45FE1BA0.5080609@nokia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
ext David Cecil wrote: > >>> 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 The problem appeared on another machine today and after I issued the "fsck_ff -B /", the console message was no longer printed. I'm going to try and determine if the umount/remount is not causing all buffers to be flushed before the underlying device becomes read-only. Regards, 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?45FF8607.8060501>