From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ljg64-0006Ov-9S for qemu-devel@nongnu.org; Tue, 17 Mar 2009 16:41:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ljg5z-0006MP-SZ for qemu-devel@nongnu.org; Tue, 17 Mar 2009 16:41:11 -0400 Received: from [199.232.76.173] (port=57236 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ljg5z-0006MI-Fr for qemu-devel@nongnu.org; Tue, 17 Mar 2009 16:41:07 -0400 Received: from mx1.redhat.com ([66.187.233.31]:45031) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ljg5y-0004Ib-Vf for qemu-devel@nongnu.org; Tue, 17 Mar 2009 16:41:07 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n2HKf66L020249 for ; Tue, 17 Mar 2009 16:41:06 -0400 From: Uri Lublin Date: Tue, 17 Mar 2009 22:40:43 +0200 Message-Id: <1237322452-11337-6-git-send-email-uril@redhat.com> In-Reply-To: <1237322452-11337-5-git-send-email-uril@redhat.com> References: <1237322452-11337-1-git-send-email-uril@redhat.com> <1237322452-11337-2-git-send-email-uril@redhat.com> <1237322452-11337-3-git-send-email-uril@redhat.com> <1237322452-11337-4-git-send-email-uril@redhat.com> <1237322452-11337-5-git-send-email-uril@redhat.com> Subject: [Qemu-devel] [PATCH 05/14] block-qcow2: keep highest allocated offset Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: 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 It does not help images which are files in a file system. The highest allocated offset is updated only upon cluster allocation (with highest offset). Currently, since we do not want to scan the refcount table (as it takes a lot of time), highest-alloc is initialized to 0. That means it may be inaccurate, but still is useful. A following patch would keep highest-alloc in a qcow2-extension, which would make it accurate. Signed-off-by: Uri Lublin --- block-qcow2.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/block-qcow2.c b/block-qcow2.c index 8a910fa..c070e05 100644 --- a/block-qcow2.c +++ b/block-qcow2.c @@ -153,6 +153,9 @@ typedef struct BDRVQcowState { uint32_t crypt_method_header; AES_KEY aes_encrypt_key; AES_KEY aes_decrypt_key; + + int64_t highest_alloc; /* highest cluester allocated (in clusters) */ + uint64_t snapshots_offset; int snapshots_size; int nb_snapshots; @@ -360,6 +363,8 @@ static int qcow_open(BlockDriverState *bs, const char *filename, int flags) if (qcow_read_extensions(bs, sizeof(header), ext_end)) goto fail; + s->highest_alloc = 0; + /* read the backing file name */ if (header.backing_file_offset != 0) { len = header.backing_file_size; @@ -2316,6 +2321,10 @@ retry: size, (s->free_cluster_index - nb_clusters) << s->cluster_bits); #endif + + if (s->highest_alloc < s->free_cluster_index) + s->highest_alloc = s->free_cluster_index; + return (s->free_cluster_index - nb_clusters) << s->cluster_bits; } -- 1.6.0.6