FFS writes to read-only mount

[David Cecil]

>> 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)