From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: qcow2 relative paths (was: [PATCH] rev5: support colon in filenames) Date: Wed, 15 Jul 2009 19:28:05 -0700 Message-ID: <1247711285.14246.116.camel@localhost> References: <1246511321.6429.31.camel@localhost> <4A4C754D.10109@redhat.com> <4A4CAD86.9020607@us.ibm.com> <4A4CB39F.5070506@redhat.com> <1247041831.6297.12.camel@localhost> <1247644283.14246.3.camel@localhost> <4A5DA1B7.5000204@siemens.com> <1247677395.14246.38.camel@localhost> <20090715182025.GC3056@shareable.org> <1247683475.14246.90.camel@localhost> <20090715210459.GJ3056@shareable.org> Reply-To: linuxram@us.ibm.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, kvm-devel To: Jamie Lokier Return-path: Received: from e34.co.us.ibm.com ([32.97.110.152]:40247 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757112AbZGPC2I (ORCPT ); Wed, 15 Jul 2009 22:28:08 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6G2OdL4002788 for ; Wed, 15 Jul 2009 20:24:39 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6G2S88e263592 for ; Wed, 15 Jul 2009 20:28:08 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6G2S78d002154 for ; Wed, 15 Jul 2009 20:28:08 -0600 In-Reply-To: <20090715210459.GJ3056@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 2009-07-15 at 22:04 +0100, Jamie Lokier wrote: > Ram Pai wrote: > > I have successfully verified qcow2 files. But then I may not be trying > > out the exact thing that you are talking about. Can you give me a test > > case that I can verify. > > Commands tried with qemu-0.10.0-1ubuntu1: > > $ mkdir unlikely_subdir > $ cd unlikely_subdir > $ qemu-img create -f qcow2 backing.img 10 > Formatting 'backing.img', fmt=qcow2, size=10 kB > $ qemu-img create -f qcow2 -b ../unlikely_subdir/backing.img main.img 10 > Formatting 'main.img', fmt=qcow2, backing_file=../unlikely_subdir/backing.img, size=10 kB > $ cd .. > $ qemu-img info unlikely_subdir/main.img > image: unlikely_subdir/main.img > file format: qcow2 > virtual size: 10K (10240 bytes) > disk size: 16K > cluster_size: 4096 > highest_alloc: 16384 > backing file: ../unlikely_subdir/backing.img (actual path: unlikely_subdir/../unlikely_subdir/backing.img) > > See especially the "actual path" line. > > $ mv unlikely_subdir other_subdir > $ ls -l other_subdir > total 32 > -rw-r--r-- 1 jamie jamie 16384 2009-07-15 21:59 backing.img > -rw-r--r-- 1 jamie jamie 16384 2009-07-15 21:59 main.img > $ qemu-img info other_subdir/main.img > qemu-img: Could not open 'other_subdir/main.img' Turns out that I did introduce a bug by deleting the call to path_combine() before calling bdrv_open() on the backing filename. However the call to realpath() is still not needed. It feels like a kludge introduced to stop path_combine() from munging backing_filename. I will send out yet another revision with the fix. I just dont' know what else I will be breaking without having a regression test harness. :( > > What an unhelpful error message... There isn't even a way to find out > the backing file path which the tool is looking for. Ok. i have introduced a message towards the effect, in the next revision of the patch. Hope that will make things a little easier. I have to go through the all the other mails to understand what has been proposed, and what I need to incorporate. Looks like a tall order. For now i will send out revision 6 in the next few hours. RP > > > And one other thing. Let me know if there a test-suite that I can try > > for regressions. > > Sorry, I don't know anything about any QEMU test suites. > > -- Jamie RP