From: utzoo!decvax!ittvax!tpdcvax!bobvan
Newsgroups: net.unix-wizards
Title: Re: quicker system startup
Article-I.D.: tpdcvax.235
Posted: Wed Dec 15 11:25:48 1982
Received: Fri Dec 17 03:02:06 1982
References: floyd.951

We (only?) have about 200 Mbytes of files split across 2 RM05's taking
about 39,000 inodes.  Fsck gets thru these in less than 5 minutes,
meaning it checks about 130 files/second (11/780 w/fpa).  Make sure
you've got the pass number field in /etc/fstab set correctly if you're
not getting similar thruput.

I'd like to suggest that we consider speeding up fsck rather than
eliminating it on clean shutdowns.  The current scheme where it forks one copy
per arm per pass number is a great improvement over just checking
serially, but I think more could be done.  Fsck is much faster on nearly
empty filesystems that on nearly full ones.  (It's much faster to check
the free list than inodes and directories.) If you have two partitions
to check on the same pass, where one is 90% full and the other is 10%
full, fsck waits for BOTH checks to finish before going on to the next
pass.  The arm containing the 10% full filesystem sits idle while fsck
slugs away on the full filesystem.  I'd like to see fsck fork one copy
of itself per ARM rather than one copy per arm per pass number.  This
should give you the maximum CPU I/O overlap.

Even though we average three boots per day, I'm not considering
skipping the fsck.  I've been keeping watch of errors fixed by fsck.
Errors fell from about 3 per boot to about 1 in 20 boots when I fixed
halt.c, but they didn't fall to zero.  My current
judgement is that the potential harm of running on a damaged filesystem
is greater than the 5 minutes "lost" while fsck runs.  This judgement
would no doubt change if we had more drives or even if our existing
disks filled up.


P.s. Our Symbolics laser printer just arrived!  No manuals and no
software.  Both are "on the way", but the novelty of watching the
self test has warn off.