Re: [Xen-users] Re: [Xen-devel] tap:qcow causes dom-U to hang in 3.0.3

[Julian Chesterfield <jac90@xxxxxxxxx>]

On 10 Nov 2006, at 14:00, Roland Paterson-Jones wrote:

> Julian Chesterfield wrote:
>
> > Can you also verify whether there's an active tapdisk process running 
> > in Dom0 for each tap:{aio,qcow} vbd. We are aware of a bug with the 
> > qcow implementation that we hope to submit a fix for very soon. It's 
> > likely that you are seeing the same issue.
> Sorry, this is not what you asked for, but this is what an 'ls' of the 
>  qcow file shows:
> [root@dom0-0-50-45-5d-6a-bc ~]# ls -als /mnt/instance_image_store_0/
> total 1564108
>      4 drwxr-xr-x  2 root root          4096 Nov 10 15:42 .
>      8 drwxr-xr-x  8 root root          4096 Nov  7 17:56 ..
> 1563132 -rw-r--r--  1 root root    1599078400 Nov 10 15:42 2
>    964 -rw-r--r--  1 root root 1099645846016 Nov 10 15:50 2.qcow
>
> It looks like the qcow file has grown to > 1000GB in (apparent) 
> size(!) Could this be the root of the problem?
Hmm, this shoudn't happen. Looks like the block offset lookup is 
screwed up.
> At this stage the dom-U is still running, but the qcow file is clearly 
> not right. The file called '2' is a loopback image backing the qcow 
> file.
> The qcow overlay was created using '/usr/sbin/qcow-create $((10*1024)) 
> /mnt/instance_image_store_0/2.qcow /mnt/instance_image_store_0/2'. I'm 
> guessing there's no danger in making the qcow overlay extent (10GB) 
> larger than the underlying loopback file extend (1.5GB) but please 
> correct me if I'm wrong.
So the current overlay support actually ignores the size value and 
creates a sparse overlay file with the same virtual size as the 
original. Technically it would be possible to create an overlay file 
larger than the source and fault read/writes for larger block offsets 
to the overlay disk, however I'm not certain this is a good idea.
> Earlier, an ls of the same directory (soon after dom-U creation) 
> looked like:
> [root@dom0-0-50-45-5d-6a-bc ~]# ls -als /mnt/instance_image_store_0/
> total 1564052
>      4 drwxr-xr-x  2 root root       4096 Nov 10 15:42 .
>      8 drwxr-xr-x  8 root root       4096 Nov  7 17:56 ..
> 1563132 -rw-r--r--  1 root root 1599078400 Nov 10 15:42 2
>    908 -rw-r--r--  1 root root     925696 Nov 10 15:43 2.qcow
>
> Could this be the root of the problem - i.e. something in the qcow 
> driver is getting it's offsets in the qcow file mangled?
> Can I try to compile the qcow (tapdisk) driver with debug enabled? 
> Where would the output go?
There's a bunch of DPRINTFs in the code which send debug output to 
syslog. You can play with syslog settings to switch on the debug 
messages and direct them to a log file.
Thanks for the file size tip, I'll explore further.

Thanks,
Julian

> Regards
> Roland
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel