From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLwbA-0006wO-87 for qemu-devel@nongnu.org; Sun, 11 Jan 2009 04:27:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLwb7-0006q3-LU for qemu-devel@nongnu.org; Sun, 11 Jan 2009 04:27:11 -0500 Received: from [199.232.76.173] (port=42165 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLwb7-0006po-HF for qemu-devel@nongnu.org; Sun, 11 Jan 2009 04:27:09 -0500 Received: from mx2.redhat.com ([66.187.237.31]:46497) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LLwb7-0000Ce-3o for qemu-devel@nongnu.org; Sun, 11 Jan 2009 04:27:09 -0500 Message-ID: <4969BB61.9070803@redhat.com> Date: Sun, 11 Jan 2009 11:26:57 +0200 From: Uri Lublin MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/3] info blockstats (block-qcow2): show highest allocated offset (bytes) References: <49664ACA.9050807@redhat.com> <4966560B.30504@codemonkey.ws> In-Reply-To: <4966560B.30504@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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org Anthony Liguori wrote: > Uri Lublin wrote: >> From: Uri Lublin >> >> This patchset let the user know the highest allocated byte of qcow2 >> images. >> Actually it's the first unallocated byte after the highest byte written, >> cluster-size aligned. >> >> The highest allocated byte gives a maximal limit (easy to calculate) >> to the number of bytes allocated for that image, and may hint how many >> more allocations can be done before we reach end-of-file (end of host >> block device). >> Although there may be many free blocks below that number (allocated >> and freed) >> the file system can not deallocate those blocks, and they have to be >> reused >> by qemu. Also note that due to fragmentation those free blocks may not >> be used on next allocations. >> >> It can be useful for truncation of backing file images (ftruncate). >> Also it may be useful for defragmentation later (although we'll need >> the number of free blocks as well). > > I'm having trouble seeing the utility of this as it seems to be not > really reliable. Surely, after a lot of work, you'll have one block far > at the end of the file, no? I don't see how knowing this location helps > practically speaking. Can you explain a little more about what you want > to use this functionality for? > Currently, qcow2 images can only grow, never shrink. The main usage would be to trigger an appropriate operation when a threshold is reached. The threshold and operation are defined by a management application. Basically we can do one of the following: 1. Defragment the qcow2 image (simplest way is to qemu-img convert it, the best is to do it online if possible). 2. Allocate more space (especially when using LVM) I plan on adding another "blockstat" that shows the number of free bytes/blocks/clusters for a qcow2 image. This would make it easier to choose the appropriate operation above. Thanks, Uri.