fsck_ufs running too often

Polytropon freebsd at edvax.de
Sat Jun 23 11:14:02 UTC 2012

On Sat, 23 Jun 2012 12:57:01 +0200, Julian H. Stacey wrote:
> > My suggestion: Set background_fsck="YES" in /etc/rc.conf and let
> > the system boot up that way. _If_ you have a faulty disk or other
> > data corruption, you'll notice this _before_ going multi-user and
> > maybe making things worse. Yes, it might take some time, but it's
> > time well invested in your data integrity.
> > 
> > Alternative: Perform a "shutdown now" and go into single-user mode.
> > Then unmount all your file systems, do "mount -o ro /" and then
> > perform the fsck run on all file systems. It's typically adviced
> > to perform file system checks on unmounted (or at least read-only
> > mounted) file systems.
> man fsck:
> -----
>              Note that background fsck is limited to checking for only the
>              most commonly occurring file system abnormalities.  Under certain
>              circumstances, some errors can escape background fsck.  It is
>              recommended that you perform foreground fsck on your systems
>              periodically and whenever you encounter file-system-related pan-
>              ics.
> ---
> So do a manual fsck to make sure there's no residual faults lurking.

Sorry, my own stupidity. Of course I wanted to say:
My suggestion: Set background_fsck="NO" in /etc/rc.conf and [...]
A fsck at boot time might take longer, but will make sure that
the startup of the system is performed on clean file systems.
One may argue: "But it takes time!" My response: Is your data
valuable? Then you have this time, in worst case. In ultra-worst
case, you have backups. :-)

> Realise fsck wont start if it thinks its clean, (but might not be clean) so
> Boot single user & type 
> 	fsck
> 	or fsck -y

You can force a fsck run by using "fsck -f"; from the manual:
"Force checking of file systems, even when they are marked
clean (for file systems that support this)." This could also
be done regularly on a scheduled (!) basis if there's the
suspection of "silent corruption" - but in such cases, better
spot the faulty hardware and replace it (bad disks, bad power
supply, bad PSU and the like).

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list