From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yle6e-0004fB-UP for qemu-devel@nongnu.org; Fri, 24 Apr 2015 09:57:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yle6e-0006TH-45 for qemu-devel@nongnu.org; Fri, 24 Apr 2015 09:57:24 -0400 Message-ID: <553A4BB7.9040000@redhat.com> Date: Fri, 24 Apr 2015 15:57:11 +0200 From: Max Reitz MIME-Version: 1.0 References: <57782138d21e277dddee0fd348a8ba437411bd64.1429875134.git.berto@igalia.com> <553A42FA.7090503@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 08/11] qemu-iotests: add no-op streaming test List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , qemu-devel@nongnu.org Cc: Kevin Wolf , qemu-block@nongnu.org, Stefan Hajnoczi On 24.04.2015 15:55, Alberto Garcia wrote: > On Fri 24 Apr 2015 03:19:54 PM CEST, Max Reitz wrote: > >>> This patch updates test_stream_partial() to test that the >>> block-stream operation never copies data from the image specified as >>> base. >> I think it would be better to add this as an own test case. But I >> won't oppose adding it as a special case of test_stream_partial >> either, because strictly speaking, streaming nothing is a special case >> of streaming partially. > That was the idea, but of course it can be moved to a new test, it's > also fine with me. > >>> + self.assertNotEqual(qemu_io('-f', iotests.imgfmt, '-c', 'map', mid_img), >>> + qemu_io('-f', iotests.imgfmt, '-c', 'map', test_img), >>> + 'image file map matches backing file after a no-op') >> Well, you haven't really proven anything by doing this, except that >> the mid_img hasn't been streamed completely into test_img... What you >> want to prove is that test_img is empty after streaming, right? > That's right, but what scenario would that be? A streaming operation > that is completed without errors and leaves partial data on the > destination image? That would be a bug. Which is what the tests are for. :-) Max > There's only 512 bytes written in mid_img for this test case. If we > suspect that it can go wrong maybe we should start comparing more things > than just the qemu_io map output... > > Berto