UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY

[Eugene Grosbein]

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