Date: Tue, 30 Sep 2008 01:37:28 +0800 From: Eugene Grosbein <eugen@kuzbass.ru> To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-stable@freebsd.org, sthaug@nethelp.no Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY Message-ID: <20080929173728.GA91107@svzserv.kemerovo.su> In-Reply-To: <48E0D8B7.4010502@quip.cz> References: <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <20080927.100458.74661341.sthaug@nethelp.no> <48E0D8B7.4010502@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 29, 2008 at 03:31:35PM +0200, Miroslav Lachman wrote: > >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. I solve this problem this way: size of /usr is 300Mb or less and it is mounted read-only, so does not have any problem with fsck (it will always skip it as clean); write activity on root fs is minimized by moving objects being modified out of root (/tmp is symlink or other fs, ntp drift is located on /var, not /etc etc.), background fsck is enabled. And you always may use /etc/rc.early to force foreground check for /var even if fsck runs in background later: #!/bin/sh /sbin/fsck -p /var || /sbin/fsck -y /var || exit 1 So, if /var was clean then fsck -p skips it, else it checks it in foreground and marks clean if possible. For serious errors, check runs again trying its best to clean /var and continue. Later background fsck skips clean (possibly fixed already) filesystems. Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080929173728.GA91107>