Hello Miles, Sunday, August 31, 2008, 8:03:45 PM, you wrote:
>>>>>> "dc" == David Collier-Brown <[EMAIL PROTECTED]> writes: MN> dc> one discovers latency growing without bound on disk MN> dc> saturation, MN> yeah, ZFS needs the same thing just for scrub. MN> I guess if the disks don't let you tag commands with priorities, then MN> you have to run them at slightly below max throughput in order to QoS MN> them. MN> It's sort of like network QoS, but not quite, because: MN> (a) you don't know exactly how big the ``pipe'' is, only MN> approximately, MN> (b) you're not QoS'ing half of a bidirectional link---you get MN> instant feedback of how long it took to ``send'' each ``packet'' MN> that you don't get with network QoS, and MN> (c) all the fabrics are lossless, so while there are queues which MN> undesireably fill up during congestion, these queues never drop MN> ``packets'' but instead exert back-pressure all the way up to MN> the top of the stack. MN> I'm surprised we survive as well as we do without disk QoS. Are the MN> storage vendors already doing it somehow? I don't know the details and haven't actually tested it but EMC provides QoS in their Clariion line... -- Best regards, Robert Milkowski mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
