Am 26.02.2026 um 16:20 hat Fiona Ebner geschrieben: > Am 24.02.26 um 3:34 PM schrieb Kevin Wolf: > > Am 16.01.2026 um 15:39 hat Fiona Ebner geschrieben: > >> With '-drive', it is possible to specify the throttle configuration > >> directly on the commandline. Add the possibility to do the same when > >> using the modern way with '-blockdev' and a front-end device. Using a > >> throttle filter block node is not always an option: in particular, the > >> mirror block job operates on a root block node and it might be desired > >> to throttle only the guest IO, but not to the block job. > > > > Hm, is there still a reason why we require a root node for the source? > > I'm not sure if the restriction could be lifted. But AFAICS, that > doesn't help in my case with a throttle node as the root node: > > Say I'm mirroring the node below throttle and the job is ready to be > completed. Further, assume that requests pile up for the root node, > while the node below is mostly idle, which can easily happen with low > throttle limits: > > At some moment, there might be no IO in-flight for the node below > throttle and thus the mirror can complete, while all the in-flight > requests for the throttle node are currently being intercepted by the > throttle group and waiting for the timer to wake them. Because, the call > to bdrv_inc_in_flight() for the node below throttle only happens after > the intercepted requests are woken. Mirror and the node below do not > know about the parent's in flight requests. Is this interpretation correct?
Well, mirror doesn't just complete by itself, but let's assume it already was ready and you told it to complete. Then yes, if there is no more activity and both sides are in sync, the mirror job can complete. However, is this any different from a mirror job completing when the guest has already put a request in the virtio-blk virtqueue, but the device model hasn't processed it yet? From the guest's perspective, the request is in flight in both cases, and from the mirror job's perspective it hasn't started yet in both cases. I think the only difference is that with throttling you might hit this case more often, but it's not a case that is fundamentally impossible without throttling. > There are scenarios where we finish the job via block-job-cancel after > freezing the guest filesystem to ensure consistency, so having > intercepted requests as described above would mess it up. Why? You got a copy that was in sync at the time that the mirror job completed. The job doesn't promise the exact point of time that the copy matches, it's just some arbitrary time after you request completion when both sides are in sync. This implies that requests after this arbitrary point in time will not be included in the copy. Though I'm also wondering, if you successfully froze the file system (as opposed to still trying to freeze it), why are we getting write requests? Shouldn't freezing involve waiting for completion of all in-flight requests? Kevin
