FFS writes to read-only mount

David Cecil david.cecil at nokia.com
Fri Mar 16 01:58:38 UTC 2007


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)



More information about the freebsd-fs mailing list