From owner-freebsd-current  Fri Mar 22 21:25:01 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id VAA29985
          for current-outgoing; Fri, 22 Mar 1996 21:25:01 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA29976
          for <freebsd-current@freefall.freebsd.org>; Fri, 22 Mar 1996 21:24:59 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id WAA04946; Fri, 22 Mar 1996 22:18:00 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199603230518.WAA04946@phaeton.artisoft.com>
Subject: Re: lost+found ???
To: bde@zeta.org.au (Bruce Evans)
Date: Fri, 22 Mar 1996 22:18:00 -0700 (MST)
Cc: bde@zeta.org.au, terry@lambert.org, freebsd-current@freefall.freebsd.org,
        joerg_wunsch@uriah.heep.sax.de, mrm@sceard.com
In-Reply-To: <199603230444.PAA08953@godzilla.zeta.org.au> from "Bruce Evans" at Mar 23, 96 03:44:44 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Or the disk drive will fail.  In my experience, total disk drive
> failures are more common than total losses of async file systems,
> except when the file system or disk driver is buggy.
> 
> Please send followups to alt.flame.fs.metadata.

8-).

> >> I think you can lose more than one directory if an inode block for a
> >> directory becomes unreadable.
> 
> >More than one directory entry; not more than the contents of one
> >directory, at least in the case of soft failures with properly
> >ordered metadata writes.
> 
> Oops, I meant a block that happens to contain the inodes for lots of
> directories.  This seems to be the worst case for the loss of a single
> ufs block.

I think what would happen is the directories would be placed in
lost+found as inode-number-named-files, and their contents would
remain untouched -- were you thinking there would be a cascade
of files going into lost+found from each of the munged directories?

> >> I wonder if fsck handles huge directories better than ufs.
> 
> >Huh? What?  This is a non-sequitur, as far as I can tell... fsck
> >is a ufs utility -- it must handle them the same.
> 
> ufs is slow for huge directories.  fsck would probably be slower if
> it used similar algorithms.  However, it knows that it only needs to
> append to lost+found (at least after it has started expanding lost+found)
> so it need not be slower than O(n) (n = number of files in lost+found).

Ah.  I think it only appends, so the answer should be "yes".


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.