Date: Mon, 29 Sep 2008 15:31:35 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> To: sthaug@nethelp.no Cc: freebsd-stable@FreeBSD.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY Message-ID: <48E0D8B7.4010502@quip.cz> In-Reply-To: <20080927.100458.74661341.sthaug@nethelp.no> References: <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <20080927.100458.74661341.sthaug@nethelp.no>
next in thread | previous in thread | raw e-mail | index | archive | help
sthaug@nethelp.no wrote: >>>IMHO, a dirty filesystem should not be mounted until it's been fully >>>analysed/scanned by fsck. So again, people are putting faith into >>>UFS2+SU despite actual evidence proving that it doesn't handle all >>>scenarios. >> >>Yes, I think the background fsck should be disabled by default, with a >>possibility to enable it if the user is sure that nothing will >>interfere with soft updates. > > > Having been bitten by problems in this area more than once, I now always > disable background fsck. Having it disabled by default has my vote too. Is there any possibility to selectively disable / enable background fsck on specified mount points? I can imagine system, where root, /usr, /var and /tmp will be checked by fsck in foreground, but waiting to foreground fsck on data partitions of about 500GB or more (it can take up tens of minutes or "hours") is scary. I need server with ssh running up "quickly" after the crash, so I can investigate what the problem was and not just sit and wait tens of minutes "if" machine gets online again or not... answering phone calls of clients in the meantime. Miroslav Lachman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48E0D8B7.4010502>