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/6642 http://kernelnewbies.org/Linux_2_6_23#head-102af265937262a7a21766ae58fddc1a29a5d8d7 I 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 <[EMAIL PROTECTED]>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}
