On Mon, Jun 14, 2021 at 4:56 PM Eric Blake wrote:
>
> On Sat, Jun 12, 2021 at 02:39:44AM +0300, Nir Soffer wrote:
> > Since this change is not simple, and the chance that we also get the dirty
> > bitmap included in the result seems to be very low, I decided to check the
> > direction of merging m
On Sat, Jun 12, 2021 at 02:39:44AM +0300, Nir Soffer wrote:
> Since this change is not simple, and the chance that we also get the dirty
> bitmap included in the result seems to be very low, I decided to check the
> direction of merging multiple extents.
>
> I started with merging "base:allocation
On Wed, Jun 9, 2021 at 9:01 PM Eric Blake wrote:
>
> When trying to reconstruct a qcow2 chain using information provided
> over NBD, ovirt had been relying on an unsafe assumption that any
> portion of the qcow2 file advertised as sparse would defer to the
> backing image; this worked with what qe
10.06.2021 17:04, Eric Blake wrote:
Maybe the thing to do is improve the documentation and try to avoid
ambiguous terminalogy; in qemu:allocation-depth, a return of depth 0
should be called "absent", not "unallocated". And in libnbd, a
base:allocation of 0 should be "data" or "normal", not "allo
10.06.2021 16:47, Eric Blake wrote:
On Thu, Jun 10, 2021 at 03:30:17PM +0300, Vladimir Sementsov-Ogievskiy wrote:
The correct fix is for ovirt to additionally use the
qemu:allocation-depth metadata context added in 5.2: after all, the
actual determination for what is needed to recreate a qcow2 f
On Thu, Jun 10, 2021 at 04:16:27PM +0300, Nir Soffer wrote:
> On Thu, Jun 10, 2021 at 2:52 AM Nir Soffer wrote:
> >
> > On Wed, Jun 9, 2021 at 9:01 PM Eric Blake wrote:
>
> I posted a work in progress patch implementing support for
> qemu:joint-allocaition
> in oVirt:
> https://gerrit.ovirt.org/
On Thu, Jun 10, 2021 at 03:30:17PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> > > The correct fix is for ovirt to additionally use the
> > > qemu:allocation-depth metadata context added in 5.2: after all, the
> > > actual determination for what is needed to recreate a qcow2 file is
> > > not whet
On Thu, Jun 10, 2021 at 02:52:10AM +0300, Nir Soffer wrote:
> > So, as a convenience, we can provide yet another metadata context,
> > "qemu:joint-allocation", which provides the bulk of the same
> > information already available from using "base:allocation" and
> > "qemu:allocation-depth" in paral
On Thu, Jun 10, 2021 at 2:52 AM Nir Soffer wrote:
>
> On Wed, Jun 9, 2021 at 9:01 PM Eric Blake wrote:
I posted a work in progress patch implementing support for
qemu:joint-allocaition
in oVirt:
https://gerrit.ovirt.org/c/ovirt-imageio/+/115197
The most important part is the nbd client:
https:/
10.06.2021 02:52, Nir Soffer wrote:
On Wed, Jun 9, 2021 at 9:01 PM Eric Blake wrote:
When trying to reconstruct a qcow2 chain using information provided
over NBD, ovirt had been relying on an unsafe assumption that any
portion of the qcow2 file advertised as sparse would defer to the
backing im
On Wed, Jun 9, 2021 at 9:01 PM Eric Blake wrote:
>
> When trying to reconstruct a qcow2 chain using information provided
> over NBD, ovirt had been relying on an unsafe assumption that any
> portion of the qcow2 file advertised as sparse would defer to the
> backing image; this worked with what qe
When trying to reconstruct a qcow2 chain using information provided
over NBD, ovirt had been relying on an unsafe assumption that any
portion of the qcow2 file advertised as sparse would defer to the
backing image; this worked with what qemu 5.2 reports for a qcow2 BSD
loaded with "backing":null.
12 matches
Mail list logo
