From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpzrA-0007YL-T5 for qemu-devel@nongnu.org; Wed, 06 May 2015 09:59:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ypzr7-0000Oa-Mq for qemu-devel@nongnu.org; Wed, 06 May 2015 09:59:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypzr7-0000OW-FE for qemu-devel@nongnu.org; Wed, 06 May 2015 09:59:21 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t46DxKkB027964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 6 May 2015 09:59:20 -0400 Date: Wed, 6 May 2015 21:59:18 +0800 From: Fam Zheng Message-ID: <20150506135918.GA31686@ad.nay.redhat.com> References: <20150505104415.GB9322@ad.nay.redhat.com> <554A1AEE.5000208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554A1AEE.5000208@redhat.com> Subject: Re: [Qemu-devel] blkdebug and VMDK (iotests 033 failure on monolithicFlat) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Wed, 05/06 15:45, Max Reitz wrote: > On 05.05.2015 12:44, Fam Zheng wrote: > >Max, > > > >Since you once fixed VMDK with the json descriptor filename, could you take a > >look at the error: > > > >$ ./check -vmdk -o "subformat=monolithicFlat" 033 > > > >033 - output mismatch (see 033.out.bad) > >--- /home/fam/qemu/tests/qemu-iotests/033.out 2015-05-05 10:52:50.524378312 +0800 > >+++ 033.out.bad 2015-05-05 17:38:36.147369924 +0800 > >@@ -2,54 +2,36 @@ > > Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 > > == preparing image == > >-wrote 1024/1024 bytes at offset 512 > >-1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) > >-wrote 1536/1536 bytes at offset 131072 > >-1.500 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) > >-wrote 131072/131072 bytes at offset 1024 > >-128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) > >+qemu-io: can't open device blkdebug::/tmp/qemu-iotests/t.vmdk: Cannot use relative extent paths with VMDK descriptor file 'json:{"image": {"driver": "file", "filename": "/tmp/qemu-iotests/t.vmdk"}, "driver": "blkdebug", "align": "512"}' > >+qemu-io: can't open device blkdebug::/tmp/qemu-iotests/t.vmdk: Cannot use relative extent paths with VMDK descriptor file 'json:{"image": {"driver": "file", "filename": "/tmp/qemu-iotests/t.vmdk"}, "driver": "blkdebug", "align": "512"}' > >+qemu-io: can't open device blkdebug::/tmp/qemu-iotests/t.vmdk: Cannot use relative extent paths with VMDK descriptor file 'json:{"image": {"driver": "file", "filename": "/tmp/qemu-iotests/t.vmdk"}, "driver": "blkdebug", "align": "512"}' > > > >... > > > > > >I'm not sure what's the best fix here. It's possible to dig out > >bs->file->file->filename in this case, but I'm not sure what's the rule of this > >filename mystery. > > > >Fam > > Hi Fam, > > The problem is that the align option is (consciously) set for blkdebug, so > the blkdebug driver cannot just convert it to a blkdebug::$foo filename, but > must create a JSON filename so that the align option is included. > > I seem to recall that someone (me? I don't know) once proposed a way for > block drivers not only to present a file name (which is json:{${baz}} in > this case), but also the name of the directory they are in, or better, a > template to which a relative path can be appended (in Unix syntax, that is, > with / as separators and .. and so on). The difference to the file name > would be that we can ignore all the options given to the block driver for > controlling its behavior, we just need a path name. > > I don't know why we didn't pursue that proposal, but it does seem to be > necessary here. > > I think we can integrate it into the existing bdrv_refresh_filename() > "infrastructure", so it shouldn't be too difficult. I can take a shot at it, > if you agree. > Sounds consistent with what we have now, but to be honest I don't have the background to agree or disagree. Could you explain (again) why does filename have to reflect its option? Fam