OK, that's one possible reason. Not sure I buy it though. If
the files are created a few days after their parent directory
then the chance of their data or metadata being within device
readhead scope of any of the parent dir's blocks seems small?
> I'm sure your benchmark doesn't fill directories with files
> by adding a few files every day over a period of many months.
> Think about projects under your home directory though.
OK. I'm not really aware of a suitable benchmark for that.
postmark only works in a single directory. mongo hardly
touches the disk at all, (with 3/4 of a gig of RAM, anyway).
My original make-100,000-4k-files test creates the files
in a tree - each node has 10 leafs. For a total of 11,110
directories and 100,000 files. It originally did it
in-order, so:
mkdir(00)
mkdir(00/00)
mkdir(00/00/00)
mkdir(00/00/00/00)
creat(00/00/00/00/00)
creat(00/00/00/00/01)
...
mkdir(00/00/00/01)
etc.
So I changed it to create the 11,110 directories, and then
to go back and create the 100,000 files. This will ensure that the
file's data are not contiguous with their parent directory.
With the ialloc.c change, plus the other changes I mentioned
the time to create all these directories and files and then run
/bin/sync fell from 1:53 to 0:28. Fourfold.
But the time to read the data was remarkable. This is purely
due to the ialloc.c change. The command was
time (find . -type f | xargs cat > /dev/null)
stock 2.4.14-pre8: 6:32
with ialloc.c change: 0:30
And this was on an 8 gig fs. On a 32 gig fs I'd expect to see
a fifteen-fold difference due to the additional block groups.
Can you suggest a better test?
-
-
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/