FFS writes to read-only mount
David Cecil
david.cecil at nokia.com
Tue Mar 20 06:59:07 UTC 2007
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)
More information about the freebsd-fs
mailing list