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
next prev 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: linkBe 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.