Hi Vladimir, can you please check your mailer settings? The plain text version of the emails is hardly legible because it mixes quotes text and replies. I had to manually open the HTML part to figure out what you really wrote.
Am 05.10.2018 um 17:00 hat Vladimir Sementsov-Ogievskiy geschrieben: > Hmm, how to share children? > > backup job has two source BdrvChild'ren - child_job and child_root of > job blk and two target BdrvChild'ren - again, child_job and > child_root. > > backup_top has source child - child_backing and second - child_file > (named "target").. Right, these are six BdrvChild instances in total. I think we can ignore the child_job ones, they are internal to the block job infrastructure, so we have four of them left. > Which BdrvChild'ren you suggest to remove? They are all different. Now that you introduced backup_top, I think we don't need any BlockBackends any more. So I suggest to remove the child_root ones and to do all I/O through the child_backing and child_file ones of backup_top. > I don't know, why job needs both unnamed blk's and child_job's, and I > don't know is it necessary for backup to use blk's not BdrvChild'ren.. I think we had a case recently where it turned out that it is strictly speaking even wrong for jobs to use BlockBackends in a function that intercepts a request on the BDS level (like the copy-before-write of backup). So getting rid of the BlockBackends isn't only okay, but actually a good thing by itself. > And with internal way in none-mode we'll have two unused blk's and > four unused BdrvChild'ren.. Or we want to rewrite backup to use > BdrvChild'ren for io operations and drop child_job BdrvChild'ren? So > I'm lost. What did you mean? child_job isn't actually unused, even though you never use them to make requests. The child_job BdrvChild is important because of the BdrvChildRole callbacks it provides to the block job infrastructure. Kevin