Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [Bug 417] New: htree much slower than regular ext3 | Date | Fri, 28 Feb 2003 05:12:56 +0100 |
| |
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 - 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/
| |