geoff@utstat.uucp (Geoff Collyer) (10/28/90)
We have an SGI 4D220 with 64Mb of main memory running Irix 3.2 with a
built-in ESDI disk and 4 SMD disks (3 Fujitsu Eagles and 1 Swallow) on a
Xylogics 754 (yer basic adequate computer). The SMD drives come from an old
Sun 3/160, where the Eagles were on a Xylogics 451 instead. One might
naively expect that the boot-time fscks would run faster on the SGI due to
having two, much faster, processors and a faster SMD controller, yet the SGI
takes 45 minutes (elapsed time) to check these drives, while the Sun took
about 15 minutes. The obvious difference is that the Sun used /etc/preen,
which in turn invokes one "fsck -p" per drive and runs all the fsck's in
parallel, whereas the SGI fscks each filesystem separately, one after the
other with no parallelism at all (truly Unparalled Performance (TM)!). I
sought to change this suboptimal state of affairs.
My first thought was to explore dfsck. Don't bother. It's full of
unchecked system calls, notably read(2)(!), and can run at most two fscks
simultaneously, which might arguably be sufficient for us with a mere two
processors, but is inadequate for a number of sites hereabout with four or
eight processors.
My next thought was to find the fsck invocation in the rc startup subtree
and replace it with an invocation of a modified preen (lacking "fsck -p",
the output would be somewhat messy, but it scrolls off the non-hardcopy
console quickly anyway). With the help of some friends, I eventually found
the boot-time fsck invocation, in /etc/mount(!).
It turns out that the rc scripts just try to mount each efs filesystem named
in /etc/fstab, and when mount (actually /etc/fsstat) determines that one is
dirty, it runs "/etc/fsck -y -D /dev/rfs". (Incidentally, someone at SGI
should lint and fix mount.c; in 3.2 at least mount_efs() doesn't return a
value in all its return statements, even though its return value is used,
and the fix in 3.3.1 looks wrong.) This is certainly surprising behaviour
for those of us accustomed to non-System-V Unixes and is rather nasty when
one wants to change the options to fsck. Fortunately, one can avoid the
magic fsck invocation in mount by explicitly fscking the filesystems (in
parallel) in the rc scripts. Here is what we are about to use (it uses the
fstab "pass" number as a "drive" number instead); does anyone, especially an
ex-4BSD or ex-Research Unix user, have anything better?
#! /bin/sh
# preen - run fsck -y -D, keeping each drive as busy as possible,
# on all read/write file systems, except the first one (root).
# avoid using /tmp or /usr/bin/sort, as they may not be mounted yet.
# N.B.: /bin/awk must exist (it does on real Unixes, but not on Irix).
PATH=/bin:/etc; export PATH
fsckbad=/etc/tmp.preen.bad
fsck=fsck # fsck or echo
# $fsck -p /dev/root
# case $? in 0) ;; *) exit $? ;; esac
rm -f $fsckbad
# collapse fstab into bins of file systems on the same drive by pass # ($6)
for args in `awk '$1 ~ /^\/dev\// && $3 == "efs" {
if (count++ > 0) { # non-root file systems, root already checked
fields = split($1, name, "/")
fss[$6] = fss[$6] "~/" name[2] "/r" name[3] # use raw device
}
}
END {
if (count > 1) # file systems other than root?
for (drive in fss)
print fss[drive]
}' /etc/fstab ` # spin off an fsck per drive
do
if eval $fsck -y -D "`echo $args | sed 's/~/ /g' `"
then : far out
else >>$fsckbad # note fsck failure
fi &
done
wait # for all the fsck's to finish
# return fsck-like exit status
if test -f $fsckbad
then exit 8
else exit 0
fi
--
Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edudaveh@xtenk.asd.sgi.com (David A Higgen) (10/30/90)
In article <1990Oct28.073438.8627@utstat.uucp>, geoff@utstat.uucp (Geoff Collyer) writes: > We have an SGI 4D220 with 64Mb of main memory running Irix 3.2 with a > built-in ESDI disk and 4 SMD disks (3 Fujitsu Eagles and 1 Swallow) on a > Xylogics 754 (yer basic adequate computer). The SMD drives come from an old > Sun 3/160, where the Eagles were on a Xylogics 451 instead. One might > naively expect that the boot-time fscks would run faster on the SGI due to > having two, much faster, processors and a faster SMD controller, yet the SGI > takes 45 minutes (elapsed time) to check these drives, while the Sun took > about 15 minutes. The obvious difference is that the Sun used /etc/preen, > which in turn invokes one "fsck -p" per drive and runs all the fsck's in > parallel, whereas the SGI fscks each filesystem separately, one after the > other with no parallelism at all (truly Unparalled Performance (TM)!). I > sought to change this suboptimal state of affairs. I'm currently in the midst of a major overhaul of fsck which will appear in the next release. I've been able to make a speed improvement of a factor 2 to 2.5 in the program itself, and there will be logic added to do parallel fsck's during bootup. Dave Higgen (daveh@xtenk.asd.sgi.com)
daveh@xtenk.asd.sgi.com (David A Higgen) (11/09/90)
> In article <73531@sgi.sgi.com> daveh@xtenk.asd.sgi.com (David A Higgen) writes: > >I'm currently in the midst of a major overhaul of fsck which will appear > >in the next release. I've been able to make a speed improvement of a factor > >2 to 2.5 in the program itself, and there will be logic added to do > >parallel fsck's during bootup. > > How about a -p option, instead of -y? Is there a good reason to have fsck > run with -y always? > > E. John Benjamins BITNET: JOHNB@MCMASTER > Computer and Information Services, Internet: johnb@sscvax.cis.mcmaster.ca > ABB 131, McMaster University, > Hamilton, Ontario, Canada "You can't chop down a symmetry" -- Jane Siberry Yes, a -p type option will be available. Unlike BSD, this will NOT be hardwired to parallel behaviour (a rotton design decision, IMHO), but will be an independant option. We will probably still ship systems with -y behaviour by default, the reason being that for the non-UNIX-experienced, you want the system to just COME UP, not require cryptic messing with some scary fsck-thing! But -p type behaviour will be available for those who want it. Dave Higgen (daveh@xtenk.asd.sgi.com)