| Message ID | 20200625152215.941773-19-mreitz@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | block: Deal with filters | expand |
On 25.06.2020 18:21, Max Reitz wrote: > If the driver does not support .bdrv_co_flush() so bdrv_co_flush() > itself has to flush the children of the given node, it should not flush > just bs->file->bs, but in fact all children that might have been written > to (judging from the permissions taken on them). > > This is a bug fix for qcow2 images with an external data file, as they > so far did not flush that data_file node. > > In any case, the BLKDBG_EVENT() should be emitted on the primary child, > because that is where a blkdebug node would be if there is any. > > Suggested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > Signed-off-by: Max Reitz <mreitz@redhat.com> > --- > block/io.c | 23 +++++++++++++++++------ > 1 file changed, 17 insertions(+), 6 deletions(-) ... > @@ int coroutine_fn bdrv_co_flush(BlockDriverState *bs) > /* Now flush the underlying protocol. It will also have BDRV_O_NO_FLUSH > * in the case of cache=unsafe, so there are no useless flushes. > */ > -flush_parent: > - ret = bs->file ? bdrv_co_flush(bs->file->bs) : 0; > +flush_children: > + ret = 0; > + QLIST_FOREACH(child, &bs->children, next) { > + if (child->perm & (BLK_PERM_WRITE | BLK_PERM_WRITE_UNCHANGED)) { > + int this_child_ret = bdrv_co_flush(child->bs); > + if (!ret) { > + ret = this_child_ret; > + } > + } > + } > + > out: > /* Notify any pending flushes that we have completed */ > if (ret == 0) { I have not tested if the running application do reaches the flush_parent point to flush the data_file but with the code it looks OK. Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
diff --git a/block/io.c b/block/io.c index 097a3861d8..c2af7711d6 100644 --- a/block/io.c +++ b/block/io.c @@ -2769,6 +2769,8 @@ static int coroutine_fn bdrv_flush_co_entry(void *opaque) int coroutine_fn bdrv_co_flush(BlockDriverState *bs) { + BdrvChild *primary_child = bdrv_primary_child(bs); + BdrvChild *child; int current_gen; int ret = 0; @@ -2798,7 +2800,7 @@ int coroutine_fn bdrv_co_flush(BlockDriverState *bs) } /* Write back cached data to the OS even with cache=unsafe */ - BLKDBG_EVENT(bs->file, BLKDBG_FLUSH_TO_OS); + BLKDBG_EVENT(primary_child, BLKDBG_FLUSH_TO_OS); if (bs->drv->bdrv_co_flush_to_os) { ret = bs->drv->bdrv_co_flush_to_os(bs); if (ret < 0) { @@ -2808,15 +2810,15 @@ int coroutine_fn bdrv_co_flush(BlockDriverState *bs) /* But don't actually force it to the disk with cache=unsafe */ if (bs->open_flags & BDRV_O_NO_FLUSH) { - goto flush_parent; + goto flush_children; } /* Check if we really need to flush anything */ if (bs->flushed_gen == current_gen) { - goto flush_parent; + goto flush_children; } - BLKDBG_EVENT(bs->file, BLKDBG_FLUSH_TO_DISK); + BLKDBG_EVENT(primary_child, BLKDBG_FLUSH_TO_DISK); if (!bs->drv) { /* bs->drv->bdrv_co_flush() might have ejected the BDS * (even in case of apparent success) */ @@ -2860,8 +2862,17 @@ int coroutine_fn bdrv_co_flush(BlockDriverState *bs) /* Now flush the underlying protocol. It will also have BDRV_O_NO_FLUSH * in the case of cache=unsafe, so there are no useless flushes. */ -flush_parent: - ret = bs->file ? bdrv_co_flush(bs->file->bs) : 0; +flush_children: + ret = 0; + QLIST_FOREACH(child, &bs->children, next) { + if (child->perm & (BLK_PERM_WRITE | BLK_PERM_WRITE_UNCHANGED)) { + int this_child_ret = bdrv_co_flush(child->bs); + if (!ret) { + ret = this_child_ret; + } + } + } + out: /* Notify any pending flushes that we have completed */ if (ret == 0) {
If the driver does not support .bdrv_co_flush() so bdrv_co_flush() itself has to flush the children of the given node, it should not flush just bs->file->bs, but in fact all children that might have been written to (judging from the permissions taken on them). This is a bug fix for qcow2 images with an external data file, as they so far did not flush that data_file node. In any case, the BLKDBG_EVENT() should be emitted on the primary child, because that is where a blkdebug node would be if there is any. Suggested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> --- block/io.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-)