lkml.org 
[lkml]   [2003]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Bug 417] New: htree much slower than regular ext3
>> > 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.

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

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.307 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site