Re: [Qemu-devel] proposed qcow2 extension: cluster reservations [was: [RFC] Proposed qcow2 extension: subcluster allocation

2017-04-24 Thread Alberto Garcia
On Sat 22 Apr 2017 07:56:57 PM CEST, Max Reitz wrote: >> So, if you got this far in reading, the question becomes whether >> having a mode where you can mark a cluster as >> mapping-reserved-but-unallocated has enough use case to be worth >> pursuing, knowing that it will burn an incompatible

Re: [Qemu-devel] proposed qcow2 extension: cluster reservations [was: [RFC] Proposed qcow2 extension: subcluster allocation

2017-04-24 Thread Kevin Wolf
Am 22.04.2017 um 19:56 hat Max Reitz geschrieben: > On 21.04.2017 23:09, Eric Blake wrote: > > And meanwhile, it looks like I have some patches to propose (and > > qemu-iotests to write) if I can help fix the bugs I've pointed out. > > You mean these? >

Re: [Qemu-devel] proposed qcow2 extension: cluster reservations [was: [RFC] Proposed qcow2 extension: subcluster allocation

2017-04-22 Thread Max Reitz
On 21.04.2017 23:09, Eric Blake wrote: > On 04/06/2017 11:40 AM, Eric Blake wrote: > >>> === Changes to the on-disk format === >>> >>> The qcow2 on-disk format needs to change so each L2 entry has a bitmap >>> indicating the allocation status of each subcluster. There are three >>> possible

[Qemu-devel] proposed qcow2 extension: cluster reservations [was: [RFC] Proposed qcow2 extension: subcluster allocation

2017-04-21 Thread Eric Blake
On 04/06/2017 11:40 AM, Eric Blake wrote: >> === Changes to the on-disk format === >> >> The qcow2 on-disk format needs to change so each L2 entry has a bitmap >> indicating the allocation status of each subcluster. There are three >> possible states (unallocated, allocated, all zeroes), so we