On 18.08.20 16:28, Kevin Wolf wrote: > Am 25.06.2020 um 17:21 hat Max Reitz geschrieben: >> Because of the (not so recent anymore) changes that make the stream job >> independent of the base node and instead track the node above it, we >> have to split that "bottom" node into two cases: The bottom COW node, >> and the node directly above the base node (which may be an R/W filter >> or the bottom COW node). >> >> Signed-off-by: Max Reitz >> --- >> qapi/block-core.json | 4 +++ >> block/stream.c | 63 ++++++++++++++++++++++++++++++++------------ >> blockdev.c | 4 ++- >> 3 files changed, 53 insertions(+), 18 deletions(-) >> >> diff --git a/qapi/block-core.json b/qapi/block-core.json >> index b20332e592..df87855429 100644 >> --- a/qapi/block-core.json >> +++ b/qapi/block-core.json >> @@ -2486,6 +2486,10 @@ >> # On successful completion the image file is updated to drop the backing file >> # and the BLOCK_JOB_COMPLETED event is emitted. >> # >> +# In case @device is a filter node, block-stream modifies the first non-filter >> +# overlay node below it to point to base's backing node (or NULL if @base was >> +# not specified) instead of modifying @device itself. > > Not to @base's backing node, but to @base itself (or actually, to > above_base's backing node, which is initially @base, but may have > changed when the job is completed). Oh, yes. (I thought I had noticed that already at some point and fixed it locally... But apparently not.) > Should we also document what using a filter node for @base means? Hm. What does it mean? I think the more interesting case is what it means if above_base is a filter, right? Maybe we can put in somewhere in the “If a base file is specified then sectors are not copied from that base file and its backing chain.” But the more I think about it, the less I know what we could add to it. What happens if there are filters above @base is that their data isn’t copied, because that’s exactly the data in @base. Max