From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypcww-0000LQ-5R for qemu-devel@nongnu.org; Tue, 05 May 2015 09:31:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ypcws-0000uf-W2 for qemu-devel@nongnu.org; Tue, 05 May 2015 09:31:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypcws-0000uB-Nj for qemu-devel@nongnu.org; Tue, 05 May 2015 09:31:46 -0400 Date: Tue, 5 May 2015 15:31:42 +0200 From: Kevin Wolf Message-ID: <20150505133142.GF3866@noname.redhat.com> References: <55424F3C.1050209@redhat.com> <20150505073609.GA9322@ad.nay.redhat.com> <554897C4.20804@redhat.com> <20150505102743.GA20503@ad.nay.redhat.com> <20150505114825.GD3866@noname.redhat.com> <5548AE65.2050405@redhat.com> <20150505130310.GE3866@noname.redhat.com> <5548C093.5040608@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5548C093.5040608@redhat.com> Subject: Re: [Qemu-devel] Fwd: qemu drive mirror assert fault List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: John Snow , Fam Zheng , qemu-devel , stefanha@redhat.com, wangxiaolong@ucloud.cn Am 05.05.2015 um 15:07 hat Paolo Bonzini geschrieben: > > > On 05/05/2015 15:03, Kevin Wolf wrote: > > > Yes, the SCSI command WRITE SAME with UNMAP = 1 (not coincidentially :)) > > > calls discard too. Who knows what the guest used it for... > > > > > > However, write zeroes doesn't go through bdrv_co_discard, does it? > > > > Initially I expected that it does, but when I checked, it turned out > > that it uses a different path. The only thing I found that really uses > > discard is the call in qemu-img that I mentioned. But that can't be the > > cause of the corruption you're debugging. > > I'm not seeing corruption; it's a crash in drive-mirror. Ah, yes, sorry. I was confused. > The question is how to treat discard: > > 1) mark sectors as dirty, discard on the destination as well (similar to > Fam's just-posted patches, but they do not discard on the destination) > > 2) keep marking sectors as not dirty, change util/hbitmap.c to avoid the > assertion failure. This loses the discard on the destination but no > need to change block/mirror.c > > Both are valid approaches. Which kind of suggests that it should be an option. But if I had to choose one, I think 1) is nicer because it results in an exact copy. Kevin