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