Path: utzoo!attcan!uunet!seismo!esosun!cogen!celerity!whoops!dave
From: dave@whoops.celerity (Dave Smith)
Newsgroups: comp.sys.next
Subject: Re: Application launch time
Message-ID: <254@celerity.UUCP>
Date: 13 Feb 89 05:57:13 GMT
References: <7554@potomac.ads.com> <116900004@p.cs.uiuc.edu>
Sender: news@celerity.UUCP
Reply-To: dave@whoops.UUCP (Dave Smith)
Organization: FPS Computing, San Diego
Lines: 29

In article <116900004@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
>Why isn't it possible to do the fsck in the background?  Couldn't just
>some *core* set of files (swap files, critical demon programs) be
>checked, then the rest of the filesystem check could go on in the
>background, after boot-up?  If a problem was found, some sort of panic
>or system interruption could happen.

Unix (and, by extension, Mach, I suppose) believes that a file system
is consistent whenever it is mounted.  If it should find something wrong
with a filesystem it will panic and crash.  It's very difficult to fix
a file system while it is mounted since a user-level program such as fsck 
will not have access to the internal buffers of the kernel and won't be able 
to tell if the filesysytem is inconsistent or if the kernel just hasn't
written everything out to disk yet.  This is a very good reason for not
running fsck on a mounted filesystem since it can make a very nasty mess
in its attempts to set things right.

One possibility for you to try is to fsck your main filesystems, then
have a background process that fsck's, then mounts each of your other
filesystems.  This is doable, but could be almost as annoying as waiting
for fsck to finish on everything if the files you use often are spread across 
several disks.



David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave
"Repent, Harlequin!," said the TickTock Man