qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Fix block migration when the device size is not


From: Pierre Riteau
Subject: Re: [Qemu-devel] [PATCH] Fix block migration when the device size is not a multiple of 1 MB
Date: Fri, 21 Jan 2011 09:08:21 +0100

Le 20 janv. 2011 à 17:18, Yoshiaki Tamura <address@hidden> a écrit :

> 2011/1/20 Pierre Riteau <address@hidden>:
>> On 20 janv. 2011, at 03:06, Yoshiaki Tamura wrote:
>> 
>>> 2011/1/19 Pierre Riteau <address@hidden>:
>>>> 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.
>>>> ---
>>>>  block-migration.c |   16 +++++++++++++++-
>>>>  1 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, int 
>>>> version_id)
>>>>     int64_t addr;
>>>>     BlockDriverState *bs;
>>>>     uint8_t *buf;
>>>> +    int64_t total_sectors;
>>>> +    int nr_sectors;
>>>> 
>>>>     do {
>>>>         addr = qemu_get_be64(f);
>>>> @@ -656,10 +658,22 @@ static int block_load(QEMUFile *f, void *opaque, int 
>>>> version_id)
>>>>                 return -EINVAL;
>>>>             }
>>>> 
>>>> +            total_sectors = bdrv_getlength(bs) >> BDRV_SECTOR_BITS;
>>>> +            if (total_sectors <= 0) {
>>>> +                fprintf(stderr, "Error getting length of block device 
>>>> %s\n", device_name);
>>>> +                return -EINVAL;
>>>> +            }
>>>> +
>>>> +            if (total_sectors - addr < BDRV_SECTORS_PER_DIRTY_CHUNK) {
>>>> +                nr_sectors = total_sectors - addr;
>>>> +            } else {
>>>> +                nr_sectors = BDRV_SECTORS_PER_DIRTY_CHUNK;
>>>> +            }
>>>> +
>>>>             buf = qemu_malloc(BLOCK_SIZE);
>>>> 
>>>>             qemu_get_buffer(f, buf, BLOCK_SIZE);
>>>> -            ret = bdrv_write(bs, addr, buf, BDRV_SECTORS_PER_DIRTY_CHUNK);
>>>> +            ret = bdrv_write(bs, addr, buf, nr_sectors);
>>>> 
>>>>             qemu_free(buf);
>>>>             if (ret < 0) {
>>>> --
>>>> 1.7.3.5
>>>> 
>>>> 
>>>> 
>>> 
>>> Hi Pierre,
>>> 
>>> I don't think the fix above is correct.  If you have a file which
>>> isn't aliened with BLOCK_SIZE, you won't get an error with the
>>> patch.  However, 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.  IIUC, 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.

At first I thought your expansion idea was best, but now I think there are 
valid scenarios where it fails. 

Imagine both sides are not using a file but a disk partition as storage. If the 
partition size is not rounded to 1 MB, the last write will fail with the 
current code, and there is no way we can expand the partition.

>> But I guess changing the protocol would be best as it would avoid headaches 
>> 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/
>> 
>> 
>> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]