Date: Sat, 23 Mar 1996 15:44:44 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Cc: freebsd-current@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, mrm@sceard.com Subject: Re: lost+found ??? Message-ID: <199603230444.PAA08953@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >Of course if you mount async, all bets are off. 8-(. >> >> I.e., lost+found only works when it is least needed :-). >Not true. If you are running async, you are obviously willing >to newfs the partition when you reboot after a crash. I've only >barely refrained from suggesting we change the option name from >"async" to "i_am_willing_to_newfs_the_partition_after_a_crash". Yes, I expect to lose it all after every 1000-100000 crashes. >Using "async" instead of, for instance, hacking in soft updates >to get the same speed effect without the attendant risks, is the >moral equivalent of picking up the soap in a Shawshank shower. >You're just *asking* for it... eventually, you will be obliged >...your power supply will fail, or your UPS will fail during a >power outage, or a cable will vibrate loose, etc., etc.. 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. >> 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 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). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603230444.PAA08953>