On 7/18/2012 2:22 AM, Stefan Ring wrote: > Because it was XFS originally which hammered the controller with this > disadvantageous pattern. Do you feel you have researched and tested this theory thoroughly enough to draw such a conclusion? Note the LSI numbers with a single thread compared to the P400. It seems at this point the LSI has no problem with the pattern. How about threaded results? > Except for the concurrency, it doesn't matter > much on which filesystem sysbench operates. I've previously verified > this on another system. It's hard to believe a 4 generation old (6-7 years) LSI ASIC with 256/512MB cache is able to sink this workload without ever stalling when flushing to rust, where the HP P2000 FC SAN array shows pretty sad performance. I'd really like to see the threaded results for the LSI at this point. I think that would be informative. > It was the Fibre Channel controller, the one with the collapsing > throughput. (P2000 G3 MSA, QLogic Corp. ISP2532-based 8Gb Fibre > Channel to PCI Express HBA) Given the LSI 1078 based RAID card with 1 thread runs circles around the P2000 with 4, 8, or 16 threads, and never stalls, with responses less than 1ms, meaning all writes hit cache, it would seem other workloads are hitting the P2000 simultaneously with your test, limiting your performance. Either that or some kind of quotas have been set on the LUNs to prevent one host from saturating the controllers. Or both. This is why I asked about exclusive access. Without it your results for the P2000 are literally worthless. Lacking complete configuration info puts you in the same boat. You simply can't draw any realistic conclusions about the P2000 performance without having complete control of the device for dedicated testing purposes. You have such control of the P400 and LSI do you not? Concentrate your testing and comparisons on those. -- Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
