On 11/14/2016 09:54 AM, Kevin Wolf wrote:
Our qcow2 support is currently limited to a maximum of 2M clusters;
while MAX_WRITE_ZEROES_BOUNCE_BUFFER is 32k * 512, or 16M. The
maximum-size bounce buffer should not be the problem here; but for some
reason, it looks like alignment
Am 14.11.2016 um 16:46 hat Eric Blake geschrieben:
> On 11/14/2016 03:50 AM, Kevin Wolf wrote:
> > Am 24.10.2016 um 22:32 hat Eric Blake geschrieben:
> >> On 10/21/2016 08:14 AM, Ed Swierk wrote:
> >>> On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake wrote:
> On 10/20/2016 07:24 PM, Ed Swierk wrot
On 11/14/2016 03:50 AM, Kevin Wolf wrote:
> Am 24.10.2016 um 22:32 hat Eric Blake geschrieben:
>> On 10/21/2016 08:14 AM, Ed Swierk wrote:
>>> On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake wrote:
On 10/20/2016 07:24 PM, Ed Swierk wrote:
> Changing max_transfer in the normal write case to
>>
Am 24.10.2016 um 22:32 hat Eric Blake geschrieben:
> On 10/21/2016 08:14 AM, Ed Swierk wrote:
> > On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake wrote:
> >> On 10/20/2016 07:24 PM, Ed Swierk wrote:
> >>> Changing max_transfer in the normal write case to
> >>> MIN_NON_ZERO(alignment, MAX_WRITE_ZEROES_
On 10/25/2016 03:39 AM, Kevin Wolf wrote:
>> It appears loop devices (with or without dm-crypt/LUKS) report a
>> 255-sector maximum per request via the BLKSECTGET ioctl, which qemu
>> rounds down to 64k in raw_refresh_limits().
Cool - I can make a loop device, so now I should have enough info to
r
Am 25.10.2016 um 01:06 hat Ed Swierk geschrieben:
> On Mon, Oct 24, 2016 at 2:21 PM, Eric Blake wrote:
> > How are you getting max_transfer == 65536? I can't reproduce it with
> > the following setup:
> >
> > $ qemu-img create -f qcow2 -o cluster_size=1M file 10M
> > $ qemu-io -f qcow2 -c 'w 7m 1
On Mon, Oct 24, 2016 at 2:21 PM, Eric Blake wrote:
> How are you getting max_transfer == 65536? I can't reproduce it with
> the following setup:
>
> $ qemu-img create -f qcow2 -o cluster_size=1M file 10M
> $ qemu-io -f qcow2 -c 'w 7m 1k' file
> $ qemu-io -f qcow2 -c 'w -z 8003584 2093056' file
>
On 10/20/2016 07:24 PM, Ed Swierk wrote:
> Shortly after I start qemu 2.7.0 with a qcow2 disk image created with
> -o cluster_size=1048576, it prints the following and dies:
>
> block/qcow2.c:2451: qcow2_co_pwrite_zeroes: Assertion `head + count <=
> s->cluster_size' failed.
>
> I narrowed the pr
On 10/21/2016 08:14 AM, Ed Swierk wrote:
> On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake wrote:
>> On 10/20/2016 07:24 PM, Ed Swierk wrote:
>>> Changing max_transfer in the normal write case to
>>> MIN_NON_ZERO(alignment, MAX_WRITE_ZEROES_BOUNCE_BUFFER) appears to fix
>>> the problem, but I don't pr
On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake wrote:
> On 10/20/2016 07:24 PM, Ed Swierk wrote:
>> Changing max_transfer in the normal write case to
>> MIN_NON_ZERO(alignment, MAX_WRITE_ZEROES_BOUNCE_BUFFER) appears to fix
>> the problem, but I don't pretend to understand all the subtleties
>> here.
On 10/20/2016 07:24 PM, Ed Swierk wrote:
> Shortly after I start qemu 2.7.0 with a qcow2 disk image created with
> -o cluster_size=1048576, it prints the following and dies:
>
> block/qcow2.c:2451: qcow2_co_pwrite_zeroes: Assertion `head + count <=
> s->cluster_size' failed.
>
> I narrowed the pr
Shortly after I start qemu 2.7.0 with a qcow2 disk image created with
-o cluster_size=1048576, it prints the following and dies:
block/qcow2.c:2451: qcow2_co_pwrite_zeroes: Assertion `head + count <=
s->cluster_size' failed.
I narrowed the problem to bdrv_co_do_pwrite_zeroes(), called by
bdrv_ali
12 matches
Mail list logo
