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

no-one can come up with a reply either quoting a mailing list or
giving the circumstances when:

a) Background fsck caused data CORRUPTION


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.
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to