Re: [Bug 417] New: htree much slower than regular ext3

[Daniel Phillips <phillips@arcor.de>]

On Thursday 27 February 2003 22:00, Andreas Dilger wrote:
> > 11 ms sounds like two seeks for each returned dirent, which sounds like a
> > bug.
>
> I think you are pretty dead on there.  The difference is that with
> unindexed entries, the directory entry and the inode are in the same order,
> while with indexed directories they are essentially in random order to each
> other.  That means that each directory lookup causes a seek to get the
> directory inode data instead of doing allocation order (which is sequential
> reads on disk).
>
> In the past both would have been slow equally, but the orlov allocator in
> 2.5 causes a number of directories to be created in the same group before
> moving on to the next group, so you have nice batches of sequential reads.

I think you're close to the truth there, but out-of-order inode table access 
would only introduce one seek per inode table block, and the cache should 
take care of the rest.  Martin's numbers suggest the cache isn't caching at 
all.

Martin, does iostat show enormously more reads for the Htree case?

Regards,

Daniel