Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!aimt!breck
From: breck@aimt.UUCP (Robert Breckinridge Beatie)
Newsgroups: comp.unix.wizards
Subject: Re: help with missing lost+found!
Message-ID: <66@aimt.UUCP>
Date: Fri, 21-Aug-87 00:33:11 EDT
Article-I.D.: aimt.66
Posted: Fri Aug 21 00:33:11 1987
Date-Received: Sat, 22-Aug-87 16:12:24 EDT
References: <44059@beno.seismo.CSS.GOV> <252@macom1.UUCP>
Organization: AIM Technology, Palo Alto, CA
Lines: 39
Summary: fsck should be able to fix lost+found

In article <252@macom1.UUCP>, michael@macom1.UUCP (Michael Mullins) writes:
> in article <44059@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) says:
> > 
> > The 4.3 BSD fsck will create a lost+found if
> > neceessary (and do some other really nice things).
> > 
> 
> 	If I have a possible hard error on the drive that is causing
> the problems in the first place, how much intellegence must fsck have
> in order to avoid that, and other problems when allocationg new blocks
> to the lost+found?

I'm not sure, since I don't have access to the source for fsck or to a 4.3 BSD
system, but it seems that it wouldn't take that much intelligence.  Shouldn't
it be possible to move the "Check Pathnames" and "Check Connectivity" phases
to the end of the list of phases.  That is, make sure that all blocks in the
free list are actually free and all blocks referenced by inodes are referenced
by only one inode.  Then any blocks fsck has to allocate to the lost+found
directory are guaranteed to be free.

As for hard errors on blocks that fsck attempts to allocate for lost+found...
Well, it's a problem.  But shouldn't such blocks already be out of the way?
On at least one system V implementation (I don't know about BSD) bad blocks are
linked to inode #1.  One possible way to work around this would be for fsck to
attempt to read the block that it attempts to allocate for lost+found.  If the
block is bad, then wouldn't the read fail giving an error condition?  fsck
could then just pick another block for allocation, flagging the original block
as bad so the administrator could take care of it.

Some more questions:  Would fsck really be able to find out if the block is
"bad" just by reading it?  Even through the block device interface?  Also, what
does 4.2 BSD do with bad blocks if it doesn't link them to inode 1?  Do you
reformat the disk and map around them?  That seems a bit extreme.  I'm really
curious about this and would appreciate any feedback anyone could give me.

Thanks.
-- 
Breck Beatie
uunet!aimt!breck