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 > . >
