On Fri, Oct 23, 2009 at 7:17 PM, Adam Cheal <ach...@pnimedia.com> wrote:
> 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. > -- > Where are you planning on queueing up those requests? The scrub, I can understand wanting throttling, but what about your user workload? Unless you're talking about EXTREMELY short bursts of I/O, what do you suggest the OS do? If you're sending 3000 IOPS at the box from a workstation, where is that workload going to sit if you're only dumping 500 IOPS to disk? The only thing that will change is that your client will timeout instead of your disks. I don't recall seeing what generates the I/O, but I do recall that it's backup. My assumption would be it's something coming in over the network, in which case I'd say you're far, far better off throttling at the network stack. --Tim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
