Question about forcing fsck at boottime

[Doug Hardie]

On Apr 6, 2009, at 11:12, Chris Rees wrote:

> Can
> no-one can come up with a reply either quoting a mailing list or
> giving the circumstances when:
>
> a) Background fsck caused data CORRUPTION
>
> _and_
>
> b) A foreground fsck would not have done the same
>
> ?

Yes.  When background FSCK first became standard I let it go that way  
on my production servers.  The first time we had a power issue that  
resulted in a shutdown of a server it tried to come back up when the  
power was restored.  I have a large number of daemons that rely on  
configure files and other information that is reasonably frequently  
updated.  Some of those files were in the process of being updated  
when it shut down.  As a result background FSCK did not get around to  
those files till much after the daemons were up and running (or trying  
to run).  Most of them worked ok at the beginning.  However after FSCK  
resolved the problems, the underlying files changed.  The daemons  
couldn't function at that point.

While a simple reboot at that point fixed everything, that caused yet  
another outage for users.  Hence, I disabled background FSCK.  There  
have been a few power issues since then and there have been no  
recovery issues with foreground FSCK other than the restart takes a  
bit longer.  This is reproducible since it happened on several  
different servers.  However, I am not about to go back and subject  
users to additional downtime when a viable workaround that avoids the  
problem exists.

I doubt that the concept of background FSCK is broken and I suspect  
that the implementation is good too.  The issue is that some services  
really should not be started till after FSCK (either variety) has  
completed.  I didn't see an easy way to do that using rc.