Re: [rfc] Near-constant time directory index for Ext2

[Mike Dresser <mdresser@windsormachine.com>]

the way i'm reading this, the problem is there's 65535 files in the directory
/where/postfix/lives.  rm * or what have you, is going to take forever and
ever, and bog the machine down while its doing it.  My understanding is you
could do the rm *, and instead of it reading the tree over and over for every
file that has to be deleted, it just jumps one or two blocks to the file that's
being deleted, instead of thousands of files to be scanned for each file
deleted.

Jeremy Jackson wrote:

> > In article <01022020011905.18944@gimli>,
> > Daniel Phillips  <phillips@innominate.de> wrote:
> > >Earlier this month a runaway installation script decided to mail all its
> > >problems to root.  After a couple of hours the script aborted, having
> > >created 65535 entries in Postfix's maildrop directory.  Removing those
> > >files took an awfully long time.  The problem is that Ext2 does each
> > >directory access using a simple, linear search though the entire
> > >directory file, resulting in n**2 behaviour to create/delete n files.
> > >It's about time we fixed that.
>
> In the case of your script I'm not sure this will help, but:
> I've seen /home directories organised like /home/a/adamsonj,
> /home/a/arthurtone, /home/b/barrettj, etc.
> this way (crude) indexing only costs areas where it's needed,
> without kernel modification. (app does it)  What other placed would we
> need indexing *in* the filesystem?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/