LSI's sales literature on that card specs "128 devices" which I take with a few hearty grains of salt. I agree that with all 46 drives pumping out streamed data, the controller would be overworked BUT the drives will only deliver data as fast as the OS tells them to. Just because the speedometer says 200 mph max doesn't mean we should (or even can!) go that fast.
The IO intensive operations that trigger our timeout issues are a small percentage of the actual normal IO we do to the box. Most of the time the solution happily serves up archived data, but when it comes time to scrub or do mass operations on the entire dataset bad things happen. It seems a waste to architect a more expensive performance-oriented solution when you aren't going to use that performance the majority of the time. There is a balance between performance and functionality, but I still feel that we should be able to make this situation work. Ideally, the OS could dynamically adapt to slower storage and throttle its IO requests accordingly. At the least, it could allow the user to specify some IO thresholds so we can "cage the beast" if need be. We've tried some manual tuning via kernel parameters to restrict max queued operations per vdev and also a "scrub" related one (specifics escape me), but it still manages to overload itself. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
