please help - explanation for odd fsck times/behavior needed

Ensel Sharon user at dhp.com
Tue Mar 14 16:10:27 UTC 2006


System is FreeBSD 6.0-RELEASE with a 400gig data partition, mounted at
/data.  I am using snapshots on that partition.

Whenever the system crashes, it comes up very quickly, and launches a
background fsck of /data.  Since this would take a long time, and I don't
want people using the system at a decreased performance, I always kill the
background fsck, comment out the filesystem in /etc/fstab, reboot the
system, and when it comes up fsck it in the foreground.  It always takes 2
hours.  Always.

So I decide that instead of doing the little boot, kill bg_fsck, comment
out, reboot dance, I will just set background_fsck="NO" in rc.conf, and
now I will just fsck in the foreground immediately after crashes.  But it
is not working that way.

Now what I see is:

- system takes 20-30 minutes to come up
- when system does come up, /data is _mounted_
- /data is in fact dirty
- if I unmount /data and fsck it, it only takes 15 minutes to fsck

So I really don't get it - especially the last two items.  Why would the
system mount /data dirty if it had no plans to background fsck it ?

The only theory I have is this:

- the boot takes a lot longer because it is fscking / and /var, NOT in the
background, and it has to wait to boot until that is finished.

- the foreground fsck of /data always took two hours before, because it
was also fsck'ing / and /var at the same time

- now that / and /var get fsck'd in the foreground before going
multi-user, it only takes 15 minutes to fsck /data


Is this ^^^ correct ?  I still don't get the logic behind mounting /data
dirty though ... is there any way to specify "fsck / and /var. and go
multi-user, but don't mount any other partitions unless they are clean" ?

Thanks.



More information about the freebsd-fs mailing list