Ted Unangst <t...@tedunangst.com> wrote:
> Mogens Jensen wrote:
> > Even after many tries, I have not yet been able to corrupt the
> > filesystem so fsck cannot repair it without manual intervention.
> > However, if power is removed while the 'reorder_kernel' script runs,
> > the system will become completely unbootable. I could do this multiple
> > times.
>
> The new kernel is installed like this:
> umask 077 && cp bsd /nbsd && mv /nbsd /bsd
>
> So a crash during compilation or linking shouldn't affect reboot. However,
> there's a window between cp and mv where some of the new kernel may reside in
> unwritten dirty buffers. Then mv will rewrite the directory entry. A crash at
> this point will leave you with a broken kernel.
I agree, dirty buffers are being pushed too slowly.
> A few possible fixes.
>
> 1. Insert a sync call in there. Kinda heavyweight, but works.
How does sync() fix this? Please explain this. Look at the source
code.
sync() is an asyncronous call requesting syncronization, and once
it has marked the blocks that should be pushed, it returns before
the work has been done.
BUGS
sync() may return before the buffers are completely flushed.
This has been marked as a bug for over half your life, to the point
where it isn't actually a bug. It is the design of the system call.
So it doesn't solve what you want to solve.
Who will be first person to says sync(); sync(); sync();
> 2. cp could do an fsync call. There was a thread about this a while ago?
How does fsync fix this? What if it returns an error. What do you do next.
Should cp spin until fsync returns non-error, or what should it do.
> 3. mv could do the fsync instead, to make sure it doesn't move incomplete
> files.
Same question.
