On Saturday, November 13, 2010 08:59:48 pm Dean S. Messing wrote: > Regarding your disk speed tests with hdparm, > you may want to look at the "--direct" switch. Oh, I like those numbers: [root@migration ~]# hdparm -t --direct /dev/sdb3 /dev/sdb3: Timing O_DIRECT disk reads: 2054 MB in 3.02 seconds = 679.13 MB/sec [root@migration ~]# hdparm -t --direct /dev/bench2/7g /dev/bench2/7g: Timing O_DIRECT disk reads: 2052 MB in 3.00 seconds = 683.36 MB/sec [root@migration ~]# There's hardware cache (about 4GB) involved in the array controller that I'm just not able to bypass. Although I'm going to admit that those numbers seem fishy... And I do know why they look fishy. There's another cache involved. But I can't reproduce with /dev/sda on that box, and /dev/sda is on the same array, it's on the same HBA, and, while it's on a different LUN, it's on the same RAID group on the array: [root@migration ~]# hdparm -t --direct /dev/sda /dev/sda: Timing O_DIRECT disk reads: 994 MB in 3.00 seconds = 331.18 MB/sec [root@migration ~]# Which is more in line with 4G/s FC performance. I'll have to dig into that anomaly. Now, on my development F14 box hooked up to the same array, just a different LUN, and a 32-bit machine (dual Xeon 2.8, 4GB RAM), and using a 2G/s FC HBA (which will impact, and probably bottleneck, performance): [root@www ~]# hdparm -t --direct /dev/sdw /dev/sdw: Timing O_DIRECT disk reads: 534 MB in 3.01 seconds = 177.46 MB/sec [root@www ~]# On another CentOS 5 box (dual 3.4GHz Xeon's, 2GB RAM, x86_64), hooked up to a different array with 4G FC: [root@backup670 ~]# hdparm -t --direct /dev/sdad /dev/sdad: Timing O_DIRECT disk reads: 864 MB in 3.00 seconds = 287.87 MB/sec [root@backup670 ~]# (yeah, /dev/sdad, that's not a typo) -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
