From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38767 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrwpX-0001Mi-QT for qemu-devel@nongnu.org; Tue, 22 Feb 2011 13:19:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrwpW-0006I6-Ka for qemu-devel@nongnu.org; Tue, 22 Feb 2011 13:19:23 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:55358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrwpW-0006I0-H0 for qemu-devel@nongnu.org; Tue, 22 Feb 2011 13:19:22 -0500 Received: by vws19 with SMTP id 19so3047661vws.4 for ; Tue, 22 Feb 2011 10:19:22 -0800 (PST) Message-ID: <4D63FE02.3040406@codemonkey.ws> Date: Tue, 22 Feb 2011 12:18:42 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Strategic decision: COW format References: <4D5BC467.4070804@redhat.com> <4D5E4271.80501@redhat.com> <4D5E8031.5020402@codemonkey.ws> <4D637A20.9020307@redhat.com> <4D63DCD6.50801@codemonkey.ws> <4D63E13C.4090705@redhat.com> In-Reply-To: <4D63E13C.4090705@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Chunqiang Tang , Markus Armbruster , Stefan Hajnoczi , qemu-devel@nongnu.org On 02/22/2011 10:15 AM, Kevin Wolf wrote: > Am 22.02.2011 16:57, schrieb Anthony Liguori: > >> On 02/22/2011 02:56 AM, Kevin Wolf wrote: >> >>> *sigh* >>> >>> It starts to get annoying, but if you really insist, I can repeat it >>> once more: These features that you don't need (this is the correct >>> description for what you call "misfeatures") _are_ implemented in a way >>> that they don't impact the "normal" case. >>> >> Except that they require a refcount table that adds additional metadata >> that needs to be updated in the fast path. I consider that impacting >> the normal case. >> > Like it or not, this requirement exists anyway, without any of your > "misfeatures". > > You chose to use the dirty flag in QED in order to avoid having to flush > metadata too often, which is an approach that any other format, even one > using refcounts, can take as well. > It's a minor detail, but flushing and the amount of metadata are separate points. The dirty flag prevents metadata from being flushed to disk very often but the use of a refcount table adds additional metadata. A refcount table is definitely not required even if you claim the requirement exists for other features. I assume you mean to implement trim/discard support but instead of a refcount table, a free list would work just as well and would leave the metadata update out of the fast path (allocating writes) and instead only be in the slow path (trim/discard). As a format feature, a refcount table really only makes sense if the refcount is required to be greater than a single bit. There are more optimal data structures that can be used if the refcount of a block is fixed to 1-bit (like a free list) which is what the fundamental design difference between qcow2 and qed is. The only use of a refcount of more than 1-bit is internal snapshots AFAICT. Regards, Anthony Liguori > Kevin >