Date: Fri, 16 Mar 2007 11:57:40 +1000 From: David Cecil <david.cecil@nokia.com> To: ext Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, ext Kris Kennaway <kris@obsecurity.org> Subject: Re: FFS writes to read-only mount Message-ID: <45F9F994.2050803@nokia.com> In-Reply-To: <20070316014846.GA3229@garage.freebsd.pl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
ext Pawel Jakub Dawidek wrote: > On Fri, Mar 16, 2007 at 08:42:20AM +1000, David Cecil wrote: > >>>> It may be that snapshots are used, but not explicitly. The startup scripts attempt to run fsck in the background, which would normally require a snapshot, but shouldn't >>>> for a read-only mount, right? >>>> >>>> >>> What happens if the filesystem is marked dirty, background fsck is >>> enabled, but the filesystem is mounted read-only? >>> >>> >> Yeah, I was wondering the same thing Kris. In fact, that was one of my first suspects when I started looking at this problem. >> >> I had eliminated it because fstat (and ps in ddb) doesn't show fsck running, or the raw device open for writing. Maybe fsck had already closed the descriptor and exited >> but the write to disk (GEOM mirror) is still outstanding in the buffer cache? >> > > Is the offset always the same for this error you're seeing? Maybe some > dirty buffer isn't flushed on disk properly and syncer retries syncing > it every now and then. This would explain why you see it not only early > after system was booted. > Yes, it's the same buffer. What you describe is what I believe I'm seeing. > 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. 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?45F9F994.2050803>