From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: Problems KVM-84 Date: Wed, 11 Mar 2009 16:06:36 +0000 Message-ID: <20090311160636.GA18390@shareable.org> References: <49B79D50.4090300@redhat.com> <49B7C6BF.6030803@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Jay Mann , Uri Lublin , kvm@vger.kernel.org To: qemu-devel@nongnu.org Return-path: Received: from mail2.shareable.org ([80.68.89.115]:60367 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751115AbZCKQGu (ORCPT ); Wed, 11 Mar 2009 12:06:50 -0400 Content-Disposition: inline In-Reply-To: <49B7C6BF.6030803@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > > 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 > > Signed-off-by: Anthony Liguori > > > >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. I still don't understand the point in that feature. You have the size of the qcow2 file (how much data is used), and the size of the image it's representing (how much it could expand to). What does the highest written offset help you anticipate? Many guest filesystems write data all over the block device, not concentrated at the start. (E.g. ext2/3/4 and it's block groups). -- Jamie