All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uri Lublin <uril@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Avi Kivity <avi@redhat.com>, Jay Mann <jmandawg@hotmail.com>,
	kvm@vger.kernel.org, Uri Lublin <ulublin@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: Problems KVM-84
Date: Wed, 11 Mar 2009 20:37:17 +0200	[thread overview]
Message-ID: <49B804DD.6010608@redhat.com> (raw)
In-Reply-To: <49B7C6BF.6030803@codemonkey.ws>

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Jay Mann wrote:
>>> Hi,
>>>
>>> I just downloaded built and installed kvm-84 on ubuntu Hardy x64  
>>> 2.6.24-23-
>>> server and I’m getting the following 2 problems that did not exists 
>>> in kvm-83.
>>>
>>> 1.    The qemu emulater (bios screen) takes a long time to start (~10 
>>> seconds), and subsequently Libvirt times out when I try to start a 
>>> guest VM from virsh.    
>>
>> This is caused by qemu r6404:
>>
>> commit 5d4cbd78aa33f6d034a62207c99ad0b64af44621
>> Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
>> Date:   Thu Jan 22 18:57:22 2009 +0000
>>
>>    block-qcow2: keep highest allocated byte (Uri Lublin)
>>      We want to know the highest written offset for qcow2 images.
>>    This gives a pretty good (and easy to calculate) estimation to how
>>    much more allocation can be done for the block device.
>>      It can be usefull for allocating more diskspace for that image
>>    (if possible, e.g. lvm) before we run out-of-disk-space
>>      Signed-off-by: Uri Lublin <uril@redhat.com>
>>    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>>
>> Scanning the file at startup is slow.  We need to find a better way.
> 
> Any quick ideas?  Seems like this is broken by design.  Unless we can 
> find a quick fix, I'm going to revert this in the stable tree.
> 
> Regards,
> 
> Anthony Liguori
> 

We only need to scan the given filename (no backing files). We can pass a flag 
to qcow_open (bdrv_open of bs->backing_hd) specifying it's a backing file.
(attached 2 patches). That makes things better for small images with big backing 
files. It does not fix the problem for very large images.

A better solution may we to allocate a qcow2-extension to keep highest-alloc and 
num-free-bytes so we don't have to scan refcount table of the image upon open.
With that solution qcow_create initializes them, qcow_open reads them and 
bdrv_close updates them. We can also add a qemu-img command to scan and update 
those values.

Regards,
     Uri.

[-- Attachment #2: 0001-block-pass-BDRV_BACKING-flag-to-backing-file-open.patch --]
[-- Type: text/x-patch, Size: 1782 bytes --]

>From 1ccf1940e0b45a9001b916bc6160c03a098a5d1d Mon Sep 17 00:00:00 2001
From: Uri Lublin <uril@redhat.com>
Date: Wed, 11 Mar 2009 20:16:23 +0200
Subject: [PATCH] block: pass BDRV_BACKING flag to backing-file open

With this information, open can behave differently for the image
filename and its backing files.

Signed-off-by: Uri Lublin <uril@redhat.com>
---
 qemu/block.c |    3 ++-
 qemu/block.h |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/qemu/block.c b/qemu/block.c
index 4c556ec..45fa5f4 100644
--- a/qemu/block.c
+++ b/qemu/block.c
@@ -397,7 +397,7 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, int flags,
     /* Note: for compatibility, we open disk image files as RDWR, and
        RDONLY as fallback */
     if (!(flags & BDRV_O_FILE))
-        open_flags = BDRV_O_RDWR | (flags & BDRV_O_CACHE_MASK);
+        open_flags = BDRV_O_RDWR | (flags & (BDRV_O_CACHE_MASK | BDRV_O_BACKING));
     else
         open_flags = flags & ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
     ret = drv->bdrv_open(bs, filename, open_flags);
@@ -429,6 +429,7 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, int flags,
         }
         path_combine(backing_filename, sizeof(backing_filename),
                      filename, bs->backing_file);
+        open_flags |= BDRV_O_BACKING;
         if (bdrv_open(bs->backing_hd, backing_filename, open_flags) < 0)
             goto fail;
     }
diff --git a/qemu/block.h b/qemu/block.h
index e1927dd..ff70d64 100644
--- a/qemu/block.h
+++ b/qemu/block.h
@@ -56,6 +56,8 @@ typedef struct QEMUSnapshotInfo {
 
 #define BDRV_O_CACHE_MASK  (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_CACHE_DEF)
 
+#define BDRV_O_BACKING     0x0100
+
 void bdrv_info(void);
 void bdrv_info_stats(void);
 
-- 
1.6.0.6


[-- Attachment #3: 0002-block-qcow2-do-not-scan-refcounts-when-opening-a-ba.patch --]
[-- Type: text/x-patch, Size: 930 bytes --]

>From c618b293a64d1690105505d7cb28ba1ca8dd33c7 Mon Sep 17 00:00:00 2001
From: Uri Lublin <uril@redhat.com>
Date: Wed, 11 Mar 2009 20:18:23 +0200
Subject: [PATCH] block-qcow2: do not scan refcounts when opening a backing file

It takes too long and is not needed.

Signed-off-by: Uri Lublin <uril@redhat.com>
---
 qemu/block-qcow2.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/qemu/block-qcow2.c b/qemu/block-qcow2.c
index 465dcd6..41cdbe9 100644
--- a/qemu/block-qcow2.c
+++ b/qemu/block-qcow2.c
@@ -276,7 +276,8 @@ static int qcow_open(BlockDriverState *bs, const char *filename, int flags)
     if (refcount_init(bs) < 0)
         goto fail;
 
-    scan_refcount(bs, &s->highest_alloc, &s->nc_free);
+    if ((flags & BDRV_O_BACKING) == 0)
+        scan_refcount(bs, &s->highest_alloc, &s->nc_free);
 
     /* read the backing file name */
     if (header.backing_file_offset != 0) {
-- 
1.6.0.6


WARNING: multiple messages have this Message-ID (diff)
From: Uri Lublin <uril@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Jay Mann <jmandawg@hotmail.com>, Uri Lublin <ulublin@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	kvm@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: Problems KVM-84
Date: Wed, 11 Mar 2009 20:37:17 +0200	[thread overview]
Message-ID: <49B804DD.6010608@redhat.com> (raw)
In-Reply-To: <49B7C6BF.6030803@codemonkey.ws>

[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Jay Mann wrote:
>>> Hi,
>>>
>>> I just downloaded built and installed kvm-84 on ubuntu Hardy x64  
>>> 2.6.24-23-
>>> server and I’m getting the following 2 problems that did not exists 
>>> in kvm-83.
>>>
>>> 1.    The qemu emulater (bios screen) takes a long time to start (~10 
>>> seconds), and subsequently Libvirt times out when I try to start a 
>>> guest VM from virsh.    
>>
>> This is caused by qemu r6404:
>>
>> commit 5d4cbd78aa33f6d034a62207c99ad0b64af44621
>> Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
>> Date:   Thu Jan 22 18:57:22 2009 +0000
>>
>>    block-qcow2: keep highest allocated byte (Uri Lublin)
>>      We want to know the highest written offset for qcow2 images.
>>    This gives a pretty good (and easy to calculate) estimation to how
>>    much more allocation can be done for the block device.
>>      It can be usefull for allocating more diskspace for that image
>>    (if possible, e.g. lvm) before we run out-of-disk-space
>>      Signed-off-by: Uri Lublin <uril@redhat.com>
>>    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>>
>> Scanning the file at startup is slow.  We need to find a better way.
> 
> Any quick ideas?  Seems like this is broken by design.  Unless we can 
> find a quick fix, I'm going to revert this in the stable tree.
> 
> Regards,
> 
> Anthony Liguori
> 

We only need to scan the given filename (no backing files). We can pass a flag 
to qcow_open (bdrv_open of bs->backing_hd) specifying it's a backing file.
(attached 2 patches). That makes things better for small images with big backing 
files. It does not fix the problem for very large images.

A better solution may we to allocate a qcow2-extension to keep highest-alloc and 
num-free-bytes so we don't have to scan refcount table of the image upon open.
With that solution qcow_create initializes them, qcow_open reads them and 
bdrv_close updates them. We can also add a qemu-img command to scan and update 
those values.

Regards,
     Uri.

[-- Attachment #2: 0001-block-pass-BDRV_BACKING-flag-to-backing-file-open.patch --]
[-- Type: text/x-patch, Size: 1782 bytes --]

>From 1ccf1940e0b45a9001b916bc6160c03a098a5d1d Mon Sep 17 00:00:00 2001
From: Uri Lublin <uril@redhat.com>
Date: Wed, 11 Mar 2009 20:16:23 +0200
Subject: [PATCH] block: pass BDRV_BACKING flag to backing-file open

With this information, open can behave differently for the image
filename and its backing files.

Signed-off-by: Uri Lublin <uril@redhat.com>
---
 qemu/block.c |    3 ++-
 qemu/block.h |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/qemu/block.c b/qemu/block.c
index 4c556ec..45fa5f4 100644
--- a/qemu/block.c
+++ b/qemu/block.c
@@ -397,7 +397,7 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, int flags,
     /* Note: for compatibility, we open disk image files as RDWR, and
        RDONLY as fallback */
     if (!(flags & BDRV_O_FILE))
-        open_flags = BDRV_O_RDWR | (flags & BDRV_O_CACHE_MASK);
+        open_flags = BDRV_O_RDWR | (flags & (BDRV_O_CACHE_MASK | BDRV_O_BACKING));
     else
         open_flags = flags & ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
     ret = drv->bdrv_open(bs, filename, open_flags);
@@ -429,6 +429,7 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, int flags,
         }
         path_combine(backing_filename, sizeof(backing_filename),
                      filename, bs->backing_file);
+        open_flags |= BDRV_O_BACKING;
         if (bdrv_open(bs->backing_hd, backing_filename, open_flags) < 0)
             goto fail;
     }
diff --git a/qemu/block.h b/qemu/block.h
index e1927dd..ff70d64 100644
--- a/qemu/block.h
+++ b/qemu/block.h
@@ -56,6 +56,8 @@ typedef struct QEMUSnapshotInfo {
 
 #define BDRV_O_CACHE_MASK  (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_CACHE_DEF)
 
+#define BDRV_O_BACKING     0x0100
+
 void bdrv_info(void);
 void bdrv_info_stats(void);
 
-- 
1.6.0.6


[-- Attachment #3: 0002-block-qcow2-do-not-scan-refcounts-when-opening-a-ba.patch --]
[-- Type: text/x-patch, Size: 930 bytes --]

>From c618b293a64d1690105505d7cb28ba1ca8dd33c7 Mon Sep 17 00:00:00 2001
From: Uri Lublin <uril@redhat.com>
Date: Wed, 11 Mar 2009 20:18:23 +0200
Subject: [PATCH] block-qcow2: do not scan refcounts when opening a backing file

It takes too long and is not needed.

Signed-off-by: Uri Lublin <uril@redhat.com>
---
 qemu/block-qcow2.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/qemu/block-qcow2.c b/qemu/block-qcow2.c
index 465dcd6..41cdbe9 100644
--- a/qemu/block-qcow2.c
+++ b/qemu/block-qcow2.c
@@ -276,7 +276,8 @@ static int qcow_open(BlockDriverState *bs, const char *filename, int flags)
     if (refcount_init(bs) < 0)
         goto fail;
 
-    scan_refcount(bs, &s->highest_alloc, &s->nc_free);
+    if ((flags & BDRV_O_BACKING) == 0)
+        scan_refcount(bs, &s->highest_alloc, &s->nc_free);
 
     /* read the backing file name */
     if (header.backing_file_offset != 0) {
-- 
1.6.0.6


  parent reply	other threads:[~2009-03-11 18:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-27  0:58 Problems KVM-84 Jay Mann
2009-02-27  6:52 ` Thomas Mueller
2009-03-09 10:22 ` Avi Kivity
2009-03-09 12:19   ` jmandawg
2009-03-09 12:19     ` jmandawg
2009-03-09 12:37       ` Avi Kivity
     [not found]         ` <BAY102-W25DF72B635B00AD337130D2A00@phx.gbl>
2009-03-10  8:39           ` Avi Kivity
     [not found]             ` <BAY102-W2139785413083807492C85D2A10@phx.gbl>
2009-03-10 13:47               ` Avi Kivity
2009-03-11 11:15 ` Avi Kivity
2009-03-11 11:15   ` [Qemu-devel] " Avi Kivity
2009-03-11 14:12   ` Anthony Liguori
2009-03-11 14:12     ` [Qemu-devel] " Anthony Liguori
2009-03-11 14:52     ` Avi Kivity
2009-03-11 20:19       ` Anthony Liguori
2009-03-11 20:19         ` Anthony Liguori
2009-03-11 16:06     ` Jamie Lokier
2009-03-11 16:06       ` Jamie Lokier
2009-03-11 22:59       ` Uri Lublin
2009-03-11 22:59         ` [Qemu-devel] " Uri Lublin
2009-03-11 18:37     ` Uri Lublin [this message]
2009-03-11 18:37       ` Uri Lublin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49B804DD.6010608@redhat.com \
    --to=uril@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=jmandawg@hotmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=ulublin@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.