freebsd stable - Jan 2005 - fsck: broken file system with background check remains broken after bootup

Hi,

I had following situation:

   Someone suddenly cut the power of a FreeBSD 5.3 PC, leaving the /usr
   filesystem in a very broken state. During next bootup, there was indeed
   the message telling 'not properly unmounted', but boot continued with
   background fsck after 60 seconds; although I have
      fsck_y_enable="YES"
   in /etc/rc.conf. Because /usr was bad, the system hang immediately after
   bootup. I had to hit the power button (grump) to get a reboot....causing
   possibly more problems.

   I fixed it, by going into single user mode and do a manual fsck on all
   the filesystems. This way /usr got fixed and the system rebooted fine.

This scared me. What if /usr was such broken that even single user mode
would hang!?!

Moreover, the main user of this PC is not a Unix guru and I hoped that
the configuration setting in /etc/rc.conf of fsck_y_enable would do an
automatic fix at bootup, like it used to do with 4.10. However, that
apparently does not happen anymore.

What can I do to enforce an immediate fix of the filesystems at bootup
with FreeBSD 5.3, when a filesystem is not properly unmounted at shutdown?

I suppose I should not change default background_fsck ("YES"). How
about
the background_fsck_delay? Should I set this to "0"?

Thanks,
Rob.

* Rob <spamrefuse@yahoo.com> [0123 10:23]:
> This scared me. What if /usr was such broken that even single user mode
> would hang!?!
That won't happen, since /usr isn't mounted in single user mode.
 

-- 
'common sense is what tells you that the world is flat.'
		-- Principia Discordia
Rasputin :: Jack of All Trades - Master of Nuns

Rob <spamrefuse@yahoo.com> writes:
> I had following situation:
>
>   Someone suddenly cut the power of a FreeBSD 5.3 PC, leaving the /usr
>   filesystem in a very broken state. During next bootup, there was indeed
>   the message telling 'not properly unmounted', but boot continued
with
>   background fsck after 60 seconds; although I have
>      fsck_y_enable="YES"
>   in /etc/rc.conf.
That is the one that may cause problems. The default fsck settings are
conservative so as to only make "safe" changes. fsck -y also makes
more
radical changes to your file system.

OTOH, I am not convinced that fsck (particularly bgfsck) is bug-free, I
have seen file system corruption on a FreeBSD 4.10 system that went with
the write caches disabled.
> This scared me. What if /usr was such broken that even single user mode
> would hang!?!
Don't worry as long as /usr is separate from /.
> Moreover, the main user of this PC is not a Unix guru and I hoped that
> the configuration setting in /etc/rc.conf of fsck_y_enable would do an
> automatic fix at bootup, like it used to do with 4.10. However, that
> apparently does not happen anymore.
>
> What can I do to enforce an immediate fix of the filesystems at bootup
> with FreeBSD 5.3, when a filesystem is not properly unmounted at shutdown?
>
> I suppose I should not change default background_fsck ("YES").
How about
> the background_fsck_delay? Should I set this to "0"?
Setting background_fsck=NO should be safe and cause the fsck to run in
foreground - exactly your desire. I would avoid touching the
background_fsck_delay.

If, as you say, the main user of the PC is not a guru and shuts down the
machine improperly, consider disabling the write cache. For ATA drives,
place hw.ata.wc="0" into /etc/loader.conf.local and reboot, for SCSI
drives, use "camcontrol modepage da0 -m8 -e -P3" and change the figure
on
the WCE: line to 0, then save and exit; repeat for all further da*
drives if you have more than one.

That will limit the potential damage on the disk to one block rather
than the whole of the cache, which is between 2 and 8 MB on the common
drives sold today.

-- 
Matthias Andree