#define AUTHOR "bad@flatlin.ka.sub.org (Christoph Badura)"

/*
 * greywolf writes:
 * 
 * >[...] 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.

I meant space for filenames...

 * 
 * Well, then I argue that there isn't a reason to reserve 4 or 8 K off a
 * file system for a lost+found.  That's insignificant compared to the
 * space you waste on inodes, bitmaps, and replicated super-blocks.

I believe you're arguing in favour of my point.  You're not saving space
for the files, you're saving space for the file *names*, which won't
take up a significant amount of space unless you have lots and LOTS of
files which need to be reconnected.  With the directory taking up one
FS block (typically 4 or 8k anyway), and assuming a filesystem with
5,000 inodes, this would result in files of length 5 ("#NNNN"), of which
a directory with 4KB allocated would nicely hold 819.

That's a _lot_ of inodes needing reconnection, folks.

 * 
 * >Besides, don't we do automagic directory collapsing?
 * 
 * I believe only when unlinking.  And a directory uses at least a FS
 * block anyway.

Yes, this is true.  I still reserve my argument that as long as you have
a lost+found, the chances are good that you're going to have room to re-
connect everything which needs it.

In case anyone missed it, running out of inodes is a moot point since
all you're doing is re-associating a name with a disconnected inode
(which is why it gets named '#<inode-number-zero-padded-to-order-of-
magnitude-of-maximum-inode-number>' instead of anything more meaningful).

But then, you all knew that. :-)

 * 
 * -- 
 * Christoph Badura	bad@flatlin.ka.sub.org		+49 721 606137
 */

#undef AUTHOR	/* "bad@flatlin.ka.sub.org (Christoph Badura)" */




				--*greywolf;
--
DAFFYNITIONS
    Regression Test (re gresh' n test) n. 1.  A simple show of hands among
    your programmers indicating how much they regret having joined your
    team.