On Fri, Apr 23, 2021 at 15:59:00 +0300, Vladimir Sementsov-Ogievskiy wrote:
Modern way is using blockdev-add + blockdev-backup, which provides a lot more control on how target is opened.
As example of drive-backup problems consider the following:
User of drive-backup expects that target will be opened in the same cache and aio mode as source. Corresponding logic is in drive_backup_prepare(), where we take bs->open_flags of source.
It works rather bad if source was added by blockdev-add. Assume source is qcow2 image. On blockdev-add we should specify aio and cache options for file child of qcow2 node. What happens next:
drive_backup_prepare() looks at bs->open_flags of qcow2 source node. But there no BDRV_O_NOCAHE neither BDRV_O_NATIVE_AIO: BDRV_O_NOCAHE is places in bs->file->bs->open_flags, and BDRV_O_NATIVE_AIO is nowhere, as file-posix parse options and simply set s->use_linux_aio.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> ---
Hi all! I remember, I suggested to deprecate drive-backup some time ago, and nobody complain.. But that old patch was inside the series with other more questionable deprecations and it did not landed.
Let's finally deprecate what should be deprecated long ago.
We now faced a problem in our downstream, described in commit message. In downstream I've fixed it by simply enabling O_DIRECT and linux_aio unconditionally for drive_backup target. But actually this just shows that using drive-backup in blockdev era is a bad idea. So let's motivate everyone (including Virtuozzo of course) to move to new interfaces and avoid problems with all that outdated option inheritance.
libvirt never used 'drive-backup' thus Reviewed-by: Peter Krempa <pkrempa@redhat.com>