Date: Fri, 22 Mar 1996 22:18:00 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, terry@lambert.org, freebsd-current@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, mrm@sceard.com Subject: Re: lost+found ??? Message-ID: <199603230518.WAA04946@phaeton.artisoft.com> In-Reply-To: <199603230444.PAA08953@godzilla.zeta.org.au> from "Bruce Evans" at Mar 23, 96 03:44:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603230518.WAA04946>