Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!aplcen!haven!adm!xadmx!XDATMNLX%DDATHD21.BITNET@cunyvm.cuny.edu
From: XDATMNLX%DDATHD21.BITNET@cunyvm.cuny.edu (Michael N. Lipp)
Newsgroups: comp.unix.questions
Subject: using fsck on mounted filesystem
Message-ID: <21534@adm.BRL.MIL>
Date: 27 Nov 89 17:34:41 GMT
Sender: news@adm.BRL.MIL
Lines: 25

Hello,

A friend of mine who is one of those poor (:-)) guys left alone with a
386-PC running unix but no unix experience showed me a problem:

He was running Microport-unix for several month and got used to trying
fsck on his mounted file-systems every now and then (don't know where
he picked that habit). Two weeks ago, he switched to Interactive-unix
and found fsck reporting a bad free block list which he had rebuilt,
but which would show up again after a reboot. I told him to boot from
floppy and fsck the file-system on the hard-disk. He did and it showed
no error. It did again, when he booted from the hard-disk afterwards.

I know he shouldn't have used fsck on the mounted file system in the
first place, but why did it work with microport-unix? I found out, that
the number of missing blocks reported matches the free space reported by
df. Interactive has the 'fast file system'. Could it be, that they write
an empty free-block-list in the superblock of a file system when mounting
it and keep the head of the free list in memory only? Thinking of a crash,
no free-list seems better to me than a false one. I persuaded him to
believe that and stop insulting unix, but I would like to make sure:
Is this the right theory or am I missing something and he will loose
his data tomorrow?

    Michael