From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Hajnoczi Subject: Re: Why QCOW1? (was: [PATCH v2] kvm tool: add QCOW verions 1 read/write support) Date: Fri, 15 Apr 2011 11:14:41 +0100 Message-ID: References: <1302722762-30517-1-git-send-email-prasadjoshi124@gmail.com> <4DA6AA2F.2020306@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Markus Armbruster , Kevin Wolf , Prasad Joshi , mingo@elte.hu, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, levinsasha928@gmail.com, stefanha@linux.vnet.ibm.com To: Pekka Enberg Return-path: Received: from mail-gw0-f46.google.com ([74.125.83.46]:37746 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752651Ab1DOKOl (ORCPT ); Fri, 15 Apr 2011 06:14:41 -0400 Received: by gwaa18 with SMTP id a18so1038247gwa.19 for ; Fri, 15 Apr 2011 03:14:41 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Apr 15, 2011 at 7:45 AM, Pekka Enberg wrote: > On Fri, Apr 15, 2011 at 9:41 AM, Markus Armbruster wrote: >> What hasn't been discussed much is the other half of Kevin's remark: why >> QCOW1? > > QCOW1 was simpler to implement as the first non-raw image format. Why even use a non-raw image format? The current implementation only does sparse files, but POSIX sparse raw files gives you the same feature. Besides, why not use btrfs or device-mapper instead of doing image formats, which ultimately duplicate file system and volume management code in userspace? Stefan