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

["Martin J. Bligh" <mbligh@aracnet.com>]

>> > 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?

Wasn't me ... I just forward the bug data from bugzilla ;-)
Filer in this case was ... bwindle-kbt@fint.org
cc'ed.

M.