qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jeff Cody
Subject: Re: [Qemu-block] [PATCH] Block: don't do copy-on-read in before_write_notifier
Date: Wed, 19 Aug 2015 10:02:49 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

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.

Thanks,
Jeff



reply via email to

[Prev in Thread] Current Thread [Next in Thread]