| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] Re: [Xen-devel] tap:qcow causes dom-U to hang in 3.0.3
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
|
|
|
| |
|
Home