From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LOXVA-0005Ln-DJ
	for qemu-devel@nongnu.org; Sun, 18 Jan 2009 08:15:44 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LOXV8-0005Jx-CZ
	for qemu-devel@nongnu.org; Sun, 18 Jan 2009 08:15:43 -0500
Received: from [199.232.76.173] (port=56992 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LOXV8-0005Jt-8k
	for qemu-devel@nongnu.org; Sun, 18 Jan 2009 08:15:42 -0500
Received: from mx2.redhat.com ([66.187.237.31]:35098)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <uril@redhat.com>) id 1LOXV7-0000pc-SR
	for qemu-devel@nongnu.org; Sun, 18 Jan 2009 08:15:42 -0500
Message-ID: <49732B76.7060509@redhat.com>
Date: Sun, 18 Jan 2009 15:15:34 +0200
From: Uri Lublin <uril@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] qcow2 format: keep 'num_free_bytes', and
	show it upon 'info blockstats'
References: <1231858339-18205-1-git-send-email-uril@redhat.com>
	<496F9494.9040402@codemonkey.ws>
In-Reply-To: <496F9494.9040402@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

Anthony Liguori wrote:
> Uri Lublin wrote:
>> 'num_free_bytes' is the number of non-allocated bytes below 
>> highest-allocation.
>>
>> Added bookkeeping to block-qcow2.c
>> Export it using BlockDeviceInfo
>> Show it upon 'info blockstats' if BlockDeviceInfo exists
>>   
> 
> What is the use case for this?

With both highest_alloc and num_free_bytes, we can have a pretty good idea
about how fragmented a qcow2 image is, and upon a threshold we can:
1. Allocate more disk space (and not wait for the disk space to run out) or
2. Defragment the image (offline: "qemu-img convert", live: yet to be implemented).

Option 1 assumes one is using LVM, or have other means for disk space 
allocation. This is especially important for "over subscription" of disk space, 
meaning the logical size of the image is larger then the disk space allocated 
for it (the physical size allocated for the image).

Currently num_free_bytes is usually pretty small (images grow a lot but not 
shrink that much). I am working on a zero-cluster optimization (originally 
written by Shahar Frank) which provides a way for the guest file system to 
"tell" qemu when blocks are freed (by writing 0's).
An exception is savevm/delvm scenario (which seems to be broken; I'll try to 
figure out what's wrong with savevm/delvm when I'll have more time available).

Thanks,
     Uri.