[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats
From: |
John Snow |
Subject: |
Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats |
Date: |
Wed, 23 Aug 2017 13:44:23 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
On 08/23/2017 01:31 PM, Max Reitz wrote:
> On 2017-08-22 21:07, John Snow wrote:
>
> [...]
>
>> (3) Add either a new flag that turns qcow2's backing file into a full
>> R/W backing file, or add a new extension to qcow2 entirely (bypassing
>> the traditional backing file mechanism to avoid confusion for older
>> tooling) that adds a new read-write backing file field.
>>
>> This RW backing file field will be used for all reads AND writes; the
>> qcow2 in question becomes a metadata container on top of the BDS chain.
>> We can re-use Vladimir's bitmap persistence extension to save bitmaps in
>> a qcow2 shell.
>>
>> The qcow2 becomes effectively a metadata cache for a new (essentially)
>> filter node that handles features such as bitmaps. This could also be
>> used to provide allocation map data for RAW files and other goodies down
>> the road.
>>
>> Hopefully this achieves our desire to not create new formats AND our
>> desire to concentrate features (and debugging, testing, etc) into qcow2,
>> while allowing users to "have bitmaps with raw files."
>>
>> Of course, in this scenario, users now have two files: a qcow2 wrapper
>> and the actual raw file in question; but regardless of how we were going
>> to solve this, a raw file necessitates an external file of some sort,
>> else we give up the idea that it was a raw file.
>>
>>
>> Sound good?
>
> While I don't quite like the idea of R/W backing files, I guess "don't
> quite like" is still rather good.
>
Yeah, it's not necessarily my first pick, but it might be the least bad.
If you have any suggestions or alternatives for a way to accomplish the
same in a way that does not leave any, even faint, bad taste in your
mouth you are more than welcome to suggest it.
> I like how this idea would allow us to use the existing code without
> putting just arbitrary binary data into the qcow2 file; the data still
> relates to the virtual disk represented by the qcow2 image.
>
> So design-wise, I don't think I have any complaints.
>
> As for Kevin, he's on PTO, though. ;-)
>
> Max
>
Ah, right. Well... I'll just have to have something fun for him to look at.
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, (continued)
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/28
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Eric Blake, 2017/08/29
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/29
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/30
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/30
Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/23
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats,
John Snow <=
Re: [Qemu-devel] [Qemu-block] Persistent bitmaps for non-qcow2 formats, Stefan Hajnoczi, 2017/08/30