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

Martin J. Bligh
2003-02-27T21:33:27Z

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