qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/5] block/qcow2-bitmap: Enable resize with pers


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH 0/5] block/qcow2-bitmap: Enable resize with persistent bitmaps
Date: Tue, 12 Mar 2019 13:39:30 +0000

12.03.2019 13:20, Kevin Wolf wrote:
> Am 11.03.2019 um 19:35 hat John Snow geschrieben:
>> On 3/11/19 2:26 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> Also, we have no comments from Max and Kevin who are maintainers of the 
>>> only file,
>>> changed in the series. And why this don't go through their trees?
>>
>> I've discussed it with Kevin in the IRC channel; I don't think he has
>> strong feelings on flushing bitmap metadata versus not as much as he
>> cares that we make sure we leave openable images on crash. In general I
>> think bitmaps are "our problem".
> 
> This, pretty much. I haven't been involved much in the bitmap code
> before, and today I have other series to deal with for soft freeze. So
> I'll trust you to do the right thing.
> 
> And the right thing means at least that after the resize operation has
> returned (either success or failure), a crash doesn't lead to an image
> file that can't be opened again.
> 
> Ideally, the same would be true for a crash in the middle the resize
> operation, but as John explained to me that we require an exact match of
> the size,

Not exact, and bitmap size is not stored in the image. But it is checked,
that bitmap table is enough to store bitmap corresponding to current image size.

  this doesn't seem to completely work out without more changes:
> Either a way to update both atomically (journal?) or at least accept
> oversized bitmaps so we can just choose the right order. The latter
> sounds tempting to me, though I haven't put much thought in the
> consequences this would have.

I think correct way is not doing this check for inconsistent bitmaps, 
considering
their size to be possibly outdated. And I've sent a counter proposal which goes
this way.

-- 
Best regards,
Vladimir

reply via email to

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