From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45089)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <vsementsov@virtuozzo.com>) id 1bq31t-0003G4-1g
	for qemu-devel@nongnu.org; Fri, 30 Sep 2016 14:59:29 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <vsementsov@virtuozzo.com>) id 1bq31n-0006u7-VJ
	for qemu-devel@nongnu.org; Fri, 30 Sep 2016 14:59:28 -0400
Received: from mailhub.sw.ru ([195.214.232.25]:42736 helo=relay.sw.ru)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <vsementsov@virtuozzo.com>) id 1bq31n-0006so-It
	for qemu-devel@nongnu.org; Fri, 30 Sep 2016 14:59:23 -0400
References: <57EE9CA4.6010801@virtuozzo.com>
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-ID: <57EEB604.1090908@virtuozzo.com>
Date: Fri, 30 Sep 2016 21:59:16 +0300
MIME-Version: 1.0
In-Reply-To: <57EE9CA4.6010801@virtuozzo.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] backup notifier fail policy
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel <qemu-devel@nongnu.org>, qemu block <qemu-block@nongnu.org>
Cc: Jeff Cody <jcody@redhat.com>, John Snow <jsnow@redhat.com>, Fam Zheng <famz@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, "Denis V. Lunev" <den@openvz.org>

On 30.09.2016 20:11, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Please, can somebody explain me, why we fail guest request in case of 
> io error in write notifier? I think guest consistency is more 
> important than success of unfinished backup. Or, what am I missing?
>
> I'm saying about this code:
>
> static int coroutine_fn backup_before_write_notify(
>         NotifierWithReturn *notifier,
>         void *opaque)
> {
>     BackupBlockJob *job = container_of(notifier, BackupBlockJob, 
> before_write);
>     BdrvTrackedRequest *req = opaque;
>     int64_t sector_num = req->offset >> BDRV_SECTOR_BITS;
>     int nb_sectors = req->bytes >> BDRV_SECTOR_BITS;
>
>     assert(req->bs == blk_bs(job->common.blk));
>     assert((req->offset & (BDRV_SECTOR_SIZE - 1)) == 0);
>     assert((req->bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
>
>     return backup_do_cow(job, sector_num, nb_sectors, NULL, true);
> }
>
> So, what about something like
>
> ret = backup_do_cow(job, ...
> if (ret < 0 && job->notif_ret == 0) {
>    job->notif_ret = ret;
> }
>
> return 0;
>
> and fail block job if notif_ret < 0 in other places of backup code?
>

And second question about notifiers in backup block job. If block job is 
paused, notifiers still works and can copy data. Is it ok? So, user 
thinks that job is paused, so he can do something with target disk.. But 
really, this 'something' will race with write-notifiers. So, what 
assumptions may user actually have about paused backup job? Is there any 
agreements? Also, on query-block-jobs we will see job.busy = false, when 
actually copy-on-write may be in flight..

-- 
Best regards,
Vladimir