From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TcxTJ-0005AX-0O for qemu-devel@nongnu.org; Mon, 26 Nov 2012 07:07:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TcxTI-0006sA-0s for qemu-devel@nongnu.org; Mon, 26 Nov 2012 07:07:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:6329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TcxTH-0006s6-P7 for qemu-devel@nongnu.org; Mon, 26 Nov 2012 07:07:31 -0500 Message-ID: <50B35B80.2010605@redhat.com> Date: Mon, 26 Nov 2012 13:07:28 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1353488464-82756-1-git-send-email-dietmar@proxmox.com> <50ACB184.5080204@redhat.com> <24E144B8C0207547AD09C467A8259F755782D8A1@lisa.maurer-it.com> <50ACCAEC.2030001@redhat.com> <24E144B8C0207547AD09C467A8259F755782F79B@lisa.maurer-it.com> <50AF3D23.2010909@redhat.com> <24E144B8C0207547AD09C467A8259F755782FA23@lisa.maurer-it.com> <24E144B8C0207547AD09C467A8259F755782FA71@lisa.maurer-it.com> <50AF5007.4030505@redhat.com> <24E144B8C0207547AD09C467A8259F7557831181@lisa.maurer-it.com> In-Reply-To: <24E144B8C0207547AD09C467A8259F7557831181@lisa.maurer-it.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/5] RFC: Efficient VM backup for qemu (v1) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: Kevin Wolf , "qemu-devel@nongnu.org" Il 26/11/2012 06:51, Dietmar Maurer ha scritto: >> Which raises the question of how to distinguish whether it's a new request to >> bs that must go through the filters or whether it actually comes from the last >> filter in the chain. As you can see, we don't have a well thought out plan yet, >> just rough ideas (otherwise it would probably be implemented already). > > The question is if I should modify my backup patch (regarding block filters)? The only solution I came up with is to add before/after hooks in the block job. I agree with the criticism, but I think it's general enough and at the same time easy enough to implement. > IMHO, the current implementation is quite simple and easy to maintain. No, "if (bs->backup_info)" simply doesn't belong in bdrv_co_writev. Paolo