On 31/03/2017 09:55, Peter Lieven wrote:
>>> Would it be an idea to introduce an inverse flag live BDRV_BLOCK_NOT_ZERO
>>> for cases where we know that there is really DATA and thus can avoid the
>>> second callout?
>> How would you know that a block is nonzero?
> I would trust the metadata. At l
Am 27.03.2017 um 17:06 schrieb Paolo Bonzini:
>
> On 27/03/2017 15:21, Peter Lieven wrote:
I stumbled across the issue with lseek on a tmpfs because in the
build process for our templates
I temporarily have vmdks on a tmpfs and it takes ages before qemu-img
convert starts to run
On 27/03/2017 15:21, Peter Lieven wrote:
>>>
>>> I stumbled across the issue with lseek on a tmpfs because in the
>>> build process for our templates
>>> I temporarily have vmdks on a tmpfs and it takes ages before qemu-img
>>> convert starts to run (it iterates
>>> over every 64kb cluster with t
Am 20.03.2017 um 17:56 schrieb Paolo Bonzini:
On 20/03/2017 17:43, Peter Lieven wrote:
Am 20.03.2017 um 15:05 schrieb Paolo Bonzini:
On 20/03/2017 14:35, Peter Lieven wrote:
Am 20.03.2017 um 14:23 schrieb Paolo Bonzini:
On 20/03/2017 14:13, Peter Lieven wrote:
Am 20.03.2017 um 13:47 schrieb
On 20/03/2017 17:43, Peter Lieven wrote:
> Am 20.03.2017 um 15:05 schrieb Paolo Bonzini:
>>
>> On 20/03/2017 14:35, Peter Lieven wrote:
>>> Am 20.03.2017 um 14:23 schrieb Paolo Bonzini:
On 20/03/2017 14:13, Peter Lieven wrote:
> Am 20.03.2017 um 13:47 schrieb Peter Lieven:
>> commit
Am 20.03.2017 um 15:05 schrieb Paolo Bonzini:
>
> On 20/03/2017 14:35, Peter Lieven wrote:
>> Am 20.03.2017 um 14:23 schrieb Paolo Bonzini:
>>> On 20/03/2017 14:13, Peter Lieven wrote:
Am 20.03.2017 um 13:47 schrieb Peter Lieven:
> commit 5daa74a6ebce7543aaad178c4061dc087bb4c705
> Auth
On 20/03/2017 14:35, Peter Lieven wrote:
> Am 20.03.2017 um 14:23 schrieb Paolo Bonzini:
>> On 20/03/2017 14:13, Peter Lieven wrote:
>>> Am 20.03.2017 um 13:47 schrieb Peter Lieven:
commit 5daa74a6ebce7543aaad178c4061dc087bb4c705
Author: Paolo Bonzini
Date: Wed Sep 4 19:00:38 20
Am 20.03.2017 um 14:23 schrieb Paolo Bonzini:
>
> On 20/03/2017 14:13, Peter Lieven wrote:
>> Am 20.03.2017 um 13:47 schrieb Peter Lieven:
>>> Am 20.03.2017 um 12:49 schrieb Fam Zheng:
On Mon, 03/20 12:21, Paolo Bonzini wrote:
> On 20/03/2017 03:46, Fam Zheng wrote:
>> On Fri, 03/17 12
On 20/03/2017 14:13, Peter Lieven wrote:
> Am 20.03.2017 um 13:47 schrieb Peter Lieven:
>> Am 20.03.2017 um 12:49 schrieb Fam Zheng:
>>> On Mon, 03/20 12:21, Paolo Bonzini wrote:
On 20/03/2017 03:46, Fam Zheng wrote:
> On Fri, 03/17 12:20, Peter Lieven wrote:
>> Am 17.03.2017 um 12:1
Am 20.03.2017 um 13:47 schrieb Peter Lieven:
> Am 20.03.2017 um 12:49 schrieb Fam Zheng:
>> On Mon, 03/20 12:21, Paolo Bonzini wrote:
>>> On 20/03/2017 03:46, Fam Zheng wrote:
On Fri, 03/17 12:20, Peter Lieven wrote:
> Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
>> On 17/03/2017 12:1
Am 20.03.2017 um 12:49 schrieb Fam Zheng:
> On Mon, 03/20 12:21, Paolo Bonzini wrote:
>>
>> On 20/03/2017 03:46, Fam Zheng wrote:
>>> On Fri, 03/17 12:20, Peter Lieven wrote:
Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
> On 17/03/2017 12:11, Peter Lieven wrote:
like VMDK or QCOW
Am 20.03.2017 um 12:49 schrieb Fam Zheng:
> On Mon, 03/20 12:21, Paolo Bonzini wrote:
>>
>> On 20/03/2017 03:46, Fam Zheng wrote:
>>> On Fri, 03/17 12:20, Peter Lieven wrote:
Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
> On 17/03/2017 12:11, Peter Lieven wrote:
like VMDK or QCOW
On Mon, 03/20 12:21, Paolo Bonzini wrote:
>
>
> On 20/03/2017 03:46, Fam Zheng wrote:
> > On Fri, 03/17 12:20, Peter Lieven wrote:
> >> Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
> >>>
> >>> On 17/03/2017 12:11, Peter Lieven wrote:
> >> like VMDK or QCOW2 shouldn't we trust the information
On 20/03/2017 03:46, Fam Zheng wrote:
> On Fri, 03/17 12:20, Peter Lieven wrote:
>> Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
>>>
>>> On 17/03/2017 12:11, Peter Lieven wrote:
>> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables
>> in the VMDK or QCOW2?
> It
On Fri, 03/17 12:20, Peter Lieven wrote:
> Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
> >
> > On 17/03/2017 12:11, Peter Lieven wrote:
> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables
> in the VMDK or QCOW2?
> >>> It provides additional information, for examp
Am 17.03.2017 um 15:51 schrieb Paolo Bonzini:
>
> On 17/03/2017 12:24, Fam Zheng wrote:
>> On Fri, 03/17 12:16, Paolo Bonzini wrote:
>>>
>>> On 17/03/2017 12:11, Peter Lieven wrote:
>> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables
>> in the VMDK or QCOW2?
> I
On 17/03/2017 12:24, Fam Zheng wrote:
> On Fri, 03/17 12:16, Paolo Bonzini wrote:
>>
>>
>> On 17/03/2017 12:11, Peter Lieven wrote:
> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables
> in the VMDK or QCOW2?
It provides additional information, for example it w
On Fri, 03/17 12:16, Paolo Bonzini wrote:
>
>
> On 17/03/2017 12:11, Peter Lieven wrote:
> >>> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables
> >>> in the VMDK or QCOW2?
> >> It provides additional information, for example it works better with
> >> prealloc=metadata.
>
Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
>
> On 17/03/2017 12:11, Peter Lieven wrote:
like VMDK or QCOW2 shouldn't we trust the information from the l2 tables
in the VMDK or QCOW2?
>>> It provides additional information, for example it works better with
>>> prealloc=metadata.
>> Oka
On 17/03/2017 12:11, Peter Lieven wrote:
>>> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables in
>>> the VMDK or QCOW2?
>> It provides additional information, for example it works better with
>> prealloc=metadata.
> Okay, understood. Can you imagine of a away to condition
Am 17.03.2017 um 11:59 schrieb Paolo Bonzini:
>
> On 17/03/2017 11:45, Peter Lieven wrote:
>> Hi,
>>
>>
>> I tried to debug why qemu-img convert with a VMDK source laying on a tmpfs
>> is horrible slow.
>>
>> For some reason a lseek on a tmpfs is slow. Strictly speaking the lseek in
>> find_alloc
On 17/03/2017 11:45, Peter Lieven wrote:
> Hi,
>
>
> I tried to debug why qemu-img convert with a VMDK source laying on a tmpfs is
> horrible slow.
>
> For some reason a lseek on a tmpfs is slow. Strictly speaking the lseek in
> find_allocation in file-posix.c
>
> is slow.
>
>
> When qemu
Hi,
I tried to debug why qemu-img convert with a VMDK source laying on a tmpfs is
horrible slow.
For some reason a lseek on a tmpfs is slow. Strictly speaking the lseek in
find_allocation in file-posix.c
is slow.
When qemu-img convert iterates over all sectors of a VMDK file to check their
23 matches
Mail list logo