OK, fine. I'm agreeing with that principle: two seeks per file is
expensive. Better two seeks for a whole bunch of files.
> : Note that I'm thinking about reading-ahead the inodes *and* the
> : blocks. If you have RAM to burn, then this looks like it should
> : work. I'm not thinking in terms of reading ahead a few piddling
> : blocks. I'm talking megabytes or dozens of megabytes.
> :
> : So with two seek operations, you can read-ahead lots of files and lots
> : of data.
>
> More brain cells, more, more, more, I want more. :-)
>
> It's a transaction cost, not a platter speed cost. Read ahead does
> not help you on small files and inodes.
I'm still missing your point, then. The way I see it, if you read in
dozens of megabytes of disc blocks into your buffer cache (and say a
megabyte of inode blocks), then things should speed up a lot.
On the first file read, you go to the inode area and read in a
megabyte. So now a truckload of inodes blocks are sitting in RAM.
Then you go to the data block area, and read in dozens of
megabytes. Now truckloads of data blocks are sitting in RAM.
On a subsequent read of another file, there is a high chance that the
inode and data blocks are sitting in the buffer cache, so there is no
transaction with the device.
Combine this with reiserfs and it may perform even better.
> Look, if things worked the way I'm describing then you should see a
> quantum leap in small file performance. Think 10x faster and you'll
> see that the number of I/O's have to go down by at least a factor of
> 10.
I don't see why my suggestion won't yield that performance
increase. Tell me why not.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/