Am 01.07.2025 um 15:04 hat Hanna Czenczek geschrieben:
> On 30.06.25 16:06, Fiona Ebner wrote:
> > In combination with using a throttle filter to enforce IO limits for
> > a guest device, knowing the 'file' child of a block device can be
> > useful. If the throttle filter is only intended for guest IO, block
> > jobs should not also be limited by the throttle filter, so the
> > block operations need to be done with the 'file' child of the top
> > throttle node as the target. In combination with mirroring, the name
> > of that child is not fixed.
> >
> > Another scenario is when unplugging a guest device after mirroring
> > below a top throttle node, where the mirror target is added explicitly
> > via blockdev-add. After mirroring, the target becomes the new 'file'
> > child of the throttle node. For unplugging, both the top throttle node
> > and the mirror target need to be deleted, because only implicitly
> > added child nodes are deleted automatically, and the current 'file'
> > child of the throttle node was explicitly added (as the mirror
> > target).
>
> Why not return a map of all children?
I had the same thought, just didn't get around to actually replying. I
think "a map" in this context will be a list of objects, like this:
"children": [
{ "child": "file", "node-name": "foo" },
{ "child": "backing", "node-name": "bar" }
]
Which as a side effect automatically gives us extensibility if we ever
want to expose more details of BdrvChild.
Kevin
