Messages in this thread | | | Date | Thu, 27 Feb 2003 13:33:20 -0800 | From | "Martin J. Bligh" <> | Subject | Re: [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/
| |