Re: [Qemu-devel] [PATCH] Block: don't do copy-on-read in before_write_notifier

[Wen Congyang <wency@cn.fujitsu.com>]

On 08/20/2015 01:02 AM, Jeff Cody wrote:
> On Wed, Aug 19, 2015 at 01:43:41PM +0800, Wen Congyang wrote:
>> On 08/19/2015 01:41 PM, Paolo Bonzini wrote:
>>> On 18/08/2015 19:54, Wen Congyang wrote:
>>>> We will copy data in before_write_notifier to do backup.
>>>> It is a nested I/O request, so we cannot do copy-on-read.
>>>
>>> Can you explain why?  What is the bug that this is fixing?
>>
>> (gdb) bt
>> #0  0x00007fd53a6cdb55 in raise () from /lib64/libc.so.6
>> #1  0x00007fd53a6cf131 in abort () from /lib64/libc.so.6
>> #2  0x00007fd53a6c6a10 in __assert_fail () from /lib64/libc.so.6
>> #3  0x00007fd53dffe5ad in wait_serialising_requests (self=0x7fd50cdb6ae0) at block/io.c:452
>> #4  0x00007fd53dfff351 in bdrv_aligned_preadv (bs=0x7fd53ea33130, req=0x7fd50cdb6ae0, offset=26347307008, bytes=65536, align=512, qiov=0x7fd50cdb6c90, flags=
>>     1) at block/io.c:847
>> #5  0x00007fd53dfff897 in bdrv_co_do_preadv (bs=0x7fd53ea33130, offset=26347307008, bytes=65536, qiov=0x7fd50cdb6c90, flags=BDRV_REQ_COPY_ON_READ)
>>     at block/io.c:970
>> #6  0x00007fd53dfff962 in bdrv_co_do_readv (bs=0x7fd53ea33130, sector_num=51459584, nb_sectors=128, qiov=0x7fd50cdb6c90, flags=0) at block/io.c:992
>> #7  0x00007fd53dfff9cf in bdrv_co_readv (bs=0x7fd53ea33130, sector_num=51459584, nb_sectors=128, qiov=0x7fd50cdb6c90) at block/io.c:1001
>> #8  0x00007fd53ddb077a in backup_do_cow (bs=0x7fd53ea33130, sector_num=51459648, nb_sectors=16, error_is_read=0x0) at block/backup.c:132
>> #9  0x00007fd53ddb0f07 in backup_before_write_notify (notifier=0x7fd5118c9f30, opaque=0x7fd50cdb6e40) at block/backup.c:193
>> #10 0x00007fd53e063193 in notifier_with_return_list_notify (list=0x7fd53ea361b8, data=0x7fd50cdb6e40) at util/notify.c:65
>> #11 0x00007fd53e000079 in bdrv_aligned_pwritev (bs=0x7fd53ea33130, req=0x7fd50cdb6e40, offset=26347339776, bytes=8192, qiov=0x7fd54001c848, flags=0)
>>     at block/io.c:1116
>> #12 0x00007fd53e000b4f in bdrv_co_do_pwritev (bs=0x7fd53ea33130, offset=26347339776, bytes=8192, qiov=0x7fd54001c848, flags=0) at block/io.c:1354
>> #13 0x00007fd53e000c18 in bdrv_co_do_writev (bs=0x7fd53ea33130, sector_num=51459648, nb_sectors=16, qiov=0x7fd54001c848, flags=0) at block/io.c:1378
>> #14 0x00007fd53e002dba in bdrv_co_do_rw (opaque=0x7fd53fb76830) at block/io.c:2113
>> #15 0x00007fd53dfafde9 in coroutine_trampoline (i0=1073594560, i1=32725) at coroutine-ucontext.c:80
>> #16 0x00007fd53a6debe0 in __correctly_grouped_prefixwc () from /lib64/libc.so.6
>> #17 0x0000000000000000 in ?? ()
>>
> 
> Can you give the steps used to reproduce this?  I ask because I am
> wondering if it would be worth adding an iotest for this or similar
> scenarios.

It is very easy to reproduce it:
1. -drive copy-on-read=on,...  // qemu option
2. drive_backup -f disk0 /path_to_backup.img // monitor command

Thanks
Wen Congyang

> 
> Thanks,
> Jeff
> .
>