From: Terry Kennedy [terry@gate.tmk.com]
Sent: Thursday, January 04, 2001 11:10 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: Giving up on VMS

Bill Todd <billtodd@foo.mv.com> writes:
> My understanding of both fsck and VMS rebuild is far from perfect, but my
> impression was that running the latter after a crash was purely optional
> (e.g., to recover 'lost' space) and generally fairly quick (in that the
> portion of the file system it must check is bounded to that space cached by
> the failed node), whereas running the former after a crash in a traditional
> Unix environment (no file system meta-data log, no soft updates) is
> absolutely mandatory (if you don't want to spread the corruption that the
> crash may have left) and can be far more lengthy.

  Well, both rebuilding and fscking are the default behavior if the file-
system is found to be marked dirty when the system restarts. I think that
implies the vendors think it's a good idea. I know mount/rebuild isn't as
thorough as analyze/disk/repair, and it's probably fairer to compare fsck
with the latter.

  "Traditional" Unix implementations would tend to go off into the weeds
if they attempted to operate on things like a corrupted directory - the
filesystem code was littered with a bunch of panic() calls if any sort of
consistency check failed. In recent years a lot of this has been fixed
(I've fixed some of it myself) - for example, you usually can't cd into
a corrupted directory now, instead of getting a panic. But since there is
no single "Unix", different implementations behave differently.

> However, I also thought that soft updates made running fsck after a crash
> optional (in something like the same sense that the VMS rebuild is), since
> they attempt to maintain on-disk consistency (modulo some possibly lost
> space at the crash instant) at all times.

  Perhaps you were thinking of lfs, the log-structured filesystem? Trad-
itional filesystem updates wrote data asynchronously and metadata synch-
ronously, which meant that deleting lots of files took a long time. The
dangerous async mount option changed the metadata operations to async as
well, but that had the usual bad effects after a crash. Soft updates
force all writes to happen asynchronously, but in a sequence that guar-
antees filesystem coherency. Another important point is that updates can
be canceled if the net result of applying an update would be no change.
For example, on a Unix system a C compilation uses the disk heavily for
work files, yet the only useful result is an executable program or object
module. So all of the updates that would have put the work files on the
disk, updated the directory, read the workfiles, and then deleted them
are voided as un-necessary.

  I haven't tried crashing a system when there are lots of updates pend-
ing, and then skipping the fsck. I should try it sometime 8-)

        Terry Kennedy             http://www.tmk.com
        terry@tmk.com             Jersey City, NJ USA