From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDGAW-0006TW-Ia for qemu-devel@nongnu.org; Wed, 06 Mar 2013 10:22:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDGAR-0007D3-Qb for qemu-devel@nongnu.org; Wed, 06 Mar 2013 10:22:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDGAR-0007Cu-JT for qemu-devel@nongnu.org; Wed, 06 Mar 2013 10:22:07 -0500 Date: Wed, 6 Mar 2013 16:22:02 +0100 From: Kevin Wolf Message-ID: <20130306152202.GC2285@dhcp-200-207.str.redhat.com> References: <20130225134551.GE3202@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557AE0931@lisa.maurer-it.com> <20130228144920.GD18389@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557B12DDC@lisa.maurer-it.com> <20130304125806.GA18476@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557B277AE@lisa.maurer-it.com> <20130304135537.GC3929@dhcp-200-207.str.redhat.com> <24E144B8C0207547AD09C467A8259F7557B278C1@lisa.maurer-it.com> <20130306124424.GE1954@stefanha-thinkpad.muc.redhat.com> <24E144B8C0207547AD09C467A8259F7557B2C525@lisa.maurer-it.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24E144B8C0207547AD09C467A8259F7557B2C525@lisa.maurer-it.com> Subject: Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: Stefan Hajnoczi , "qemu-devel@nongnu.org" Am 06.03.2013 um 15:42 hat Dietmar Maurer geschrieben: > > > > Maybe you'd better use a different output format that doesn't > > > > restrict you to 64k writes. > > > > > > The output format is not really the restriction. The problem is that > > > an additional IPC layer add overhead, an d I do not want that (because it is > > totally unnecessary). > > > > I missed the reason why you cannot increase the block size. > > When we run backup, we need to read such block on every write from the guest. > So if we increase block size we get additional delays. How about variable block sizes? I mean this is a stream format that has a header for each block anyway. Include a size there and be done. Kevin