Sorry, I forgot to mention the Linux kernel version I'm using, etc:
2.6.18-92.1.10.el5 #1 SMP x86_64
CentOS 5.2.
The "adaptive" read-ahead, as well as other enhancements in the kernel, are taking place or coming soon in the most recent stuff. Some distributions offer the adaptive read-ahead as an add-on (Debian, for example). This is an area where much can be improved in Linux
http://kerneltrap.org/node/6642http://kernelnewbies.org/Linux_2_6_23#head-102af265937262a7a21766ae58fddc1a29a5d8d7I obviously did not test how the new read-ahead stuff impacts these sorts of tests.
On Thu, Sep 11, 2008 at 12:07 PM, Scott Carey
<scott@richrelevance.com> wrote:
Hmm, I would expect this tunable to potentially be rather file system dependent, and potentially raid controller dependant. The test was using ext2, perhaps the others automatically prefetch or read ahead? Does it vary by RAID controller?
Well I went and found out, using ext3 and xfs. I have about 120+ data points but here are a few interesting ones before I compile the rest and answer a few other questions of my own.
1: readahead does not affect "pure" random I/O -- there seems to be a heuristic trigger -- a single process or file probably has to request a sequence of linear I/O of some size to trigger it. I set it to over 64MB of read-ahead and random iops remained the same to prove this.
2: File system matters more than you would expect. XFS sequential transfers when readahead was tuned had TWICE the sequential throughput of ext3, both for a single reader and 8 concurrent readers on 8 different files.
3: The RAID controller and its configuration make a pretty significant difference as well.
Hardware:
12 7200RPM SATA (Seagate) in raid 10 on 3Ware 9650 (only ext3)
12 7200RPM SATA ('nearline SAS' : Seagate ES.2) on PERC 6 in raid 10 (ext3, xfs)
I also have some results with PERC raid 10 with 4x 15K SAS, not reporting in this message though
. . . {snip}