From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52050 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfxEA-0005nY-6K for qemu-devel@nongnu.org; Thu, 20 Jan 2011 11:19:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfxE8-0007vH-T4 for qemu-devel@nongnu.org; Thu, 20 Jan 2011 11:19:14 -0500 Received: from mail-ew0-f45.google.com ([209.85.215.45]:39608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfxE8-0007vA-LW for qemu-devel@nongnu.org; Thu, 20 Jan 2011 11:19:12 -0500 Received: by ewy10 with SMTP id 10so377153ewy.4 for ; Thu, 20 Jan 2011 08:19:11 -0800 (PST) MIME-Version: 1.0 Sender: tamura.yoshiaki@gmail.com In-Reply-To: <04350B7C-9933-4A70-8FA9-B5B409D1E10A@irisa.fr> References: <1295449188-17877-1-git-send-email-Pierre.Riteau@irisa.fr> <04350B7C-9933-4A70-8FA9-B5B409D1E10A@irisa.fr> Date: Fri, 21 Jan 2011 01:18:25 +0900 Message-ID: Subject: Re: [Qemu-devel] [PATCH] Fix block migration when the device size is not a multiple of 1 MB From: Yoshiaki Tamura Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pierre Riteau Cc: kwolf@redhat.com, qemu-devel@nongnu.org 2011/1/20 Pierre Riteau : > On 20 janv. 2011, at 03:06, Yoshiaki Tamura wrote: > >> 2011/1/19 Pierre Riteau : >>> b02bea3a85cc939f09aa674a3f1e4f36d418c007 added a check on the return >>> value of bdrv_write and aborts migration when it fails. However, if the >>> size of the block device to migrate is not a multiple of BLOCK_SIZE >>> (currently 1 MB), the last bdrv_write will fail with -EIO. >>> >>> Fixed by calling bdrv_write with the correct size of the last block. >>> --- >>> =A0block-migration.c | =A0 16 +++++++++++++++- >>> =A01 files changed, 15 insertions(+), 1 deletions(-) >>> >>> diff --git a/block-migration.c b/block-migration.c >>> index 1475325..eeb9c62 100644 >>> --- a/block-migration.c >>> +++ b/block-migration.c >>> @@ -635,6 +635,8 @@ static int block_load(QEMUFile *f, void *opaque, in= t version_id) >>> =A0 =A0 int64_t addr; >>> =A0 =A0 BlockDriverState *bs; >>> =A0 =A0 uint8_t *buf; >>> + =A0 =A0int64_t total_sectors; >>> + =A0 =A0int nr_sectors; >>> >>> =A0 =A0 do { >>> =A0 =A0 =A0 =A0 addr =3D qemu_get_be64(f); >>> @@ -656,10 +658,22 @@ static int block_load(QEMUFile *f, void *opaque, = int version_id) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL; >>> =A0 =A0 =A0 =A0 =A0 =A0 } >>> >>> + =A0 =A0 =A0 =A0 =A0 =A0total_sectors =3D bdrv_getlength(bs) >> BDRV_S= ECTOR_BITS; >>> + =A0 =A0 =A0 =A0 =A0 =A0if (total_sectors <=3D 0) { >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, "Error getting length = of block device %s\n", device_name); >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -EINVAL; >>> + =A0 =A0 =A0 =A0 =A0 =A0} >>> + >>> + =A0 =A0 =A0 =A0 =A0 =A0if (total_sectors - addr < BDRV_SECTORS_PER_DI= RTY_CHUNK) { >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nr_sectors =3D total_sectors - addr; >>> + =A0 =A0 =A0 =A0 =A0 =A0} else { >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nr_sectors =3D BDRV_SECTORS_PER_DIRTY_= CHUNK; >>> + =A0 =A0 =A0 =A0 =A0 =A0} >>> + >>> =A0 =A0 =A0 =A0 =A0 =A0 buf =3D qemu_malloc(BLOCK_SIZE); >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 qemu_get_buffer(f, buf, BLOCK_SIZE); >>> - =A0 =A0 =A0 =A0 =A0 =A0ret =3D bdrv_write(bs, addr, buf, BDRV_SECTORS= _PER_DIRTY_CHUNK); >>> + =A0 =A0 =A0 =A0 =A0 =A0ret =3D bdrv_write(bs, addr, buf, nr_sectors); >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 qemu_free(buf); >>> =A0 =A0 =A0 =A0 =A0 =A0 if (ret < 0) { >>> -- >>> 1.7.3.5 >>> >>> >>> >> >> Hi Pierre, >> >> I don't think the fix above is correct. =A0If you have a file which >> isn't aliened with BLOCK_SIZE, you won't get an error with the >> patch. =A0However, the receiver doesn't know how much sectors which >> the sender wants to be written, so the guest may fail after >> migration because some data may not be written. =A0IIUC, although >> changing bytestream should be prevented as much as possible, we >> should save/load total_sectors to check appropriate file is >> allocated on the receiver side. > > Isn't the guest supposed to be started using a file with the correct size= ? I personally don't like that; It's insisting too much to the user. Can't we expand the image on the fly? We can just abort if expanding failed anyway. > But I guess changing the protocol would be best as it would avoid headach= es to people who mistakenly created a file that is too small. We should think carefully before changing the protocol. Kevin? > >> BTW, you should use error_report instead of fprintf(stderr, ...). > > I didn't know that, I followed what was used in this file. Thank you. > > -- > Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France > http://perso.univ-rennes1.fr/pierre.riteau/ > > >