UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
eugen at kuzbass.ru
Mon Sep 29 17:37:33 UTC 2008
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:
/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.
More information about the freebsd-stable