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