2009/4/5 Chris Rees <utis...@googlemail.com>:
> 2009/3/31 Oliver Fromme <o...@lurza.secnetix.de>:
>> Chris Rees <utis...@googlemail.com> wrote:
>> > 2009/3/31 Wojciech Puchar <woj...@wojtek.tensor.gdynia.pl>:
>> > >
>> > > IMHO this background fsck isn't good idea at all
>> > Why?
>> Google "background fsck damage".
>> I was bitten by it myself, and I also recommend to turn
>> background fsck off. If your disks are large and you
>> can't afford the fsck time, consider using ZFS, which
>> has a lot of benefits besides not requiring fsck.
>> Best regards
> Right... You were bitten by background fsck, what _exactly_ happened?
> All the 'problems' here associated with bgfsck are referring to
> FreeBSD 4 etc, or incredibly vague anecdotal evidence. Have you
> googled for background fsck damage? Nothing (in the first two pages at
> least) even suggests that background fsck causes damage.
> Erik Trulsson wrote:
>> Normal PATA/SATA disks with write caching enabled (which is the default) do
>> not provide these guarantees. Disabling write caching on will make them
>> adhere to the assumptions that soft updates make, but at the cost of a
>> severe performance penalty when writing to the disks.
>> In short therefore on a 'typical' PC you can fairly easily get errors on a
>> filesystem which background fsck cannot handle.
> What do you mean by handle? Sure, it won't fix them, but it'll at
> least detect them. The chances of actually having a problem are slim,
> anyway, and it won't cause any damage either.
This is exactly my experience: maybe three times in years
of various power failures and hardware barfs have I had the
background fsck tell me to run fsck manually. And that is the
entire extent of the "failure". The system was running normally,
if a bit slowly from the fsck itself, and the worst result was a
disappeared /var/db/pkg directory (which had nothing to do
with fsck being in the background on restart).
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"