From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=50832 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q1hdV-000854-WF
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 12:07:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Q1hdR-0006hw-Na
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 12:07:14 -0400
Received: from mail-iw0-f173.google.com ([209.85.214.173]:37934)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Q1hdR-0006hi-KI
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 12:07:13 -0400
Received: by iwl42 with SMTP id 42so7563703iwl.4
	for <qemu-devel@nongnu.org>; Mon, 21 Mar 2011 09:07:12 -0700 (PDT)
Message-ID: <4D87770F.3080407@codemonkey.ws>
Date: Mon, 21 Mar 2011 11:04:31 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Moving beyond image files
References: <4D876930.6000106@us.ibm.com>
	<145C4163-3365-4A73-B2F2-EC397669D363@suse.de>
In-Reply-To: <145C4163-3365-4A73-B2F2-EC397669D363@suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.nongnu.org/archive/html/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: Alexander Graf <agraf@suse.de>
Cc: Kevin Wolf <kwolf@redhat.com>, Chunqiang Tang <ctang@us.ibm.com>, Eric Van Hensbergen <ericvh@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>

On 03/21/2011 10:16 AM, Alexander Graf wrote:
> On 21.03.2011, at 16:05, Anthony Liguori wrote:
>
>>
>> 5) Copy-on-write references potentially become very interesting for image streaming because you can avoid any I/O for blocks that are already stored locally.
>>
>> This is not fully baked yet but I thought I'd at least throw it out there as a topic for discussion.  I think we've focused almost entirely on single images so I think it's worth thinking a little about different storage models.
> Wouldn't it make sense to have your file system be that daemon

I see that as purely an implementation detail.

Regards,

Anthony Liguori

>   and add an interface to it so you can receive the sha1 sums (that you need for dedup anyways) to calculate rsync style diffs?
>
> That way you'd also speed up 2 other use cases:
>
>    a) normal raw storage - no need to implement new protocols, file formats, etc
>    b) real rsync on real data that is not vm images
>
>
> Alex
>
>