Question about forcing fsck at boottime

Chris Rees utisoft at googlemail.com
Tue Apr 7 02:34:16 PDT 2009


>
> 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
>>
>> ?
2009/4/6 Doug Hardie <bc979 at lafn.org>:

> 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.
<snip>

So, the answer is NO, it does NOT cause data CORRUPTION. A simple
reboot solved it? Really, you're advocating guaranteed extended
downtime every time there's a power outage, compared with a slight
chance of a slightly longer downtime while every other time it comes
almost straight up.

Any more replies, please, read the damned question.

> I doubt that the concept of background FSCK is broken and I suspect that the implementation is good too.

_Thank_ you

Chris


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


More information about the freebsd-questions mailing list