From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbAGy-0005Qm-D4 for qemu-devel@nongnu.org; Wed, 21 Nov 2012 08:23:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbAGo-0000rc-PC for qemu-devel@nongnu.org; Wed, 21 Nov 2012 08:23:24 -0500 Received: from mail-ia0-f173.google.com ([209.85.210.173]:63898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbAGo-0000rW-Ke for qemu-devel@nongnu.org; Wed, 21 Nov 2012 08:23:14 -0500 Received: by mail-ia0-f173.google.com with SMTP id w21so3638589iac.4 for ; Wed, 21 Nov 2012 05:23:13 -0800 (PST) Sender: Paolo Bonzini Message-ID: <50ACD5BC.2080006@redhat.com> Date: Wed, 21 Nov 2012 14:23:08 +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> In-Reply-To: <50ACCAEC.2030001@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Kevin Wolf Cc: Dietmar Maurer , "qemu-devel@nongnu.org" Il 21/11/2012 13:37, Kevin Wolf ha scritto: >>> >> The active part is a bit more tricky. You're putting some code into block.c to >>> >> achieve it, which is kind of ugly. >> > >> > yes. but I tried to keep that small ;-) > Yup, it's already not too bad. I haven't looked into it in much detail, > but I'd like to reduce it even a bit more. In particular, the > backup_info field in the BlockDriverState feels wrong to me. In the long > term the generic block layer shouldn't know at all what a backup is, and > baking it into BDS couples it very tightly. My plan was to have something like bs->job->job_type->{before,after}_write. int coroutine_fn (*before_write)(BlockDriverState *bs, int64_t sector_num, int nb_sectors, QEMUIOVector *qiov, void **cookie); int coroutine_fn (*after_write)(BlockDriverState *bs, int64_t sector_num, int nb_sectors, QEMUIOVector *qiov, void *cookie); The before_write could optionally return a "cookie" that is passed back to the after_write callback. Actually this was plan B, as a poor-man implementation of the filter infrastructure. Plan A was that the block filters would materialize suddenly in someone's git tree. Anyway, it should be very easy to convert Dietmar's code to something like that, and the active mirror could use it as well. >> > AFAIK qcow2 file cannot store data out of order. In general, an backup fd is not seekable, >> > and we only want to do sequential writes. Image format always requires seekable fds? > Ah, this is what you mean by "out of order". Just out of curiosity, what > are these non-seekable backup fds usually? Perhaps I've been reading the SCSI standards too much lately, but tapes come to mind. :) Paolo