From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS6lX-0000zz-V3 for qemu-devel@nongnu.org; Wed, 19 Aug 2015 13:03:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS6lS-00012V-91 for qemu-devel@nongnu.org; Wed, 19 Aug 2015 13:03:07 -0400 Date: Wed, 19 Aug 2015 10:02:49 -0700 From: Jeff Cody Message-ID: <20150819170249.GA21260@localhost.localdomain> References: <55D3EFF4.7030004@cn.fujitsu.com> <55D41714.6030903@redhat.com> <55D4178D.70006@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55D4178D.70006@cn.fujitsu.com> Subject: Re: [Qemu-devel] [PATCH] Block: don't do copy-on-read in before_write_notifier List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Kevin Wolf , Paolo Bonzini , Stefan Hajnoczi , qemu-devl , qemu block 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