Date: Fri, 22 Mar 1996 20:59:15 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: mrm@sceard.com, terry@lambert.org, freebsd-current@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: lost+found ??? Message-ID: <199603230359.UAA04471@phaeton.artisoft.com> In-Reply-To: <199603230150.MAA02055@godzilla.zeta.org.au> from "Bruce Evans" at Mar 23, 96 12:50:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >On the subject of the 8k, Bruce is wrong about the requirements: the > >most you have to deal with is the number of files allowed to be a > >problem with properly ordered updates: basically, one directory > >worth of names... and in that case, you'll get blocks back from > >the directory that died. It's still possible to overflow the 16 > >additional (reserved) blocks, but it's unlikely. > > >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". It's a good idea, but those of us who are too gung-ho to wait for the writes to be done correctly are probably also too gung-ho to be done typing the mount command to get onto typing the next command after that, so it would never fly. 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.. > 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. > 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. 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?199603230359.UAA04471>