Subject: Re: what makes lost+found in NetBSD?
To: Erik E. Fair <email@example.com>
From: After 5 PM please slip brain through slot in door. <greywolf@defender.VAS.viewlogic.com>
Date: 11/07/1995 12:43:56
#define AUTHOR "firstname.lastname@example.org ("Erik E. Fair" (Time Keeper))"
* Provided that your Fast Filesystem has stayed 10% free (even when "full"),
* fsck should be able to find enough blocks to create a lost+found. This also
* means that you could create a trivial script to walk the local mount points
* and check for the existence of lost+found and report that to "root" for
* further investigation. Hmmm.
You are assuming that:
- minfree is 10%
- I meant "full, less minfree".
In fact, I meant "full". As in "uid 0: write failed: No space left on
device" full. As in "You have tromped all over minfree. Go directly to
disk space hell. Do not asm("jmpa $_start"); do not collect even 200
bytes of disk space" full.
As in "You forgot to make /usr big enough" full. As in "You have forgotten
to delete the last five kernels from the root filesystem" full.
I could go on, but I think I've made my point. There is no way in hell
that fsck is going to be able to create lost+found in that case, but, again,
disk space isn't at *that* much of a premium any more, so there's no real
reason to reserve 8K of space for inode relocation.
Besides, don't we do automagic directory collapsing? I thought that was
part of 4.3 which carried over to 4.4 and 4.4.1, 4.4.2, etc...
* Erik Fair
#undef AUTHOR /* "email@example.com ("Erik E. Fair" (Time Keeper))" */
Sun hardware is great stuff. It's too bad their software has taken
such a downturn.