Hi Greg, Thanks for sharing the insight. If we limit the scope of QoS to a RBD image, some QoS mechanism will still be beneficial. As there is an effort to asynchronously flattern a image, the priority for flattern operation should be lower than normal I/O to limit the latency, right? Cheng Cheng On Thu, Jan 15, 2015 at 12:59 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: > On Thu, Jan 15, 2015 at 9:53 AM, Cheng Cheng <ccheng.leo@xxxxxxxxx> wrote: >> Hi Ceph, >> >> I am wondering is there a mechanism to prioritize the rbd_aio_write/rbd_aio_read I/Os? Currently all RBD I/Os are issued in FIFO to rados layer, and there is NO QoS mechanism to control the priority of these I/Os. >> >> A QoS mechanism will be beneficial when performing certain management operations, such as flatten. When flatten a image, the outstanding I/Os do get throttled by “rbd_concurrent_management_ops”. However this won't guarantee normal I/Os are not affected, as outstanding normal I/Os are still competing with concurrent management ops. >> >> Anyone know how/where to implement this QoS mechanism? > > Sadly, there's no QoS in RBD right now. It sounds like you're more > concerned about preventing management from impacting client IO, but > even in this case it's a distributed problem (flatten for instance > involves moving data between storage machines), which is still an open > research topic as far as I know. I don't think you'll ever be able to > get a guarantee, and simply doing one movement at a time is probably > as good as you can get in the medium term. :( > -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
