[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system fo

From: MORITA Kazutaka
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU
Date: Thu, 13 May 2010 04:46:46 +0900
User-agent: Thunderbird (Windows/20090302)

On 2010/05/12 20:38, Kevin Wolf wrote:
> Am 12.05.2010 12:46, schrieb MORITA Kazutaka:
>> Hi all,
>> This patch adds a block driver for Sheepdog distributed storage
>> system.  Please consider for inclusion.
>> Sheepdog is a distributed storage system for QEMU.  It provides highly
>> available block level storage volumes to VMs like Amazon EBS.
>> Sheepdog features are:
>> - No node in the cluster is special (no metadata node, no control
>>   node, etc)
>> - Linear scalability in performance and capacity
>> - No single point of failure
>> - Autonomous management (zero configuration)
>> - Useful volume management support such as snapshot and cloning
>> - Thin provisioning
>> - Autonomous load balancing
>> The more details are available at the project site [1] and my previous
>> post about sheepdog [2].
>> We have implemented the essential part of sheepdog features, and
>> believe the API between Sheepdog and QEMU is finalized.
>> Any comments or suggestions would be greatly appreciated.
> These patches don't apply, neither on git master nor on the block
> branch. Please rebase them on git://repo.or.cz/qemu/kevin.git block for
> the next submission.

Ok, I'll rebase them and resend later. Sorry for inconvenience.

> I'll have a closer look at your code later, but one thing I noticed is
> that the new block driver is something in between a protocol and a
> format driver (just like vvfat, which should stop doing so, too). I
> think it ought to be a real protocol with the raw format driver on top
> (or any other format - I don't see a reason why this should be
> restricted to raw).
> The one thing that is unusual about it as a protocol driver is that it
> supports snapshots. However, while it is the first one, supporting
> snapshots in protocols is a thing that could be generally useful to
> support (for example thinking of a LVM protocol, which was discussed in
> the past).

I agreed.  I'll modify the sheepdog driver patch as a protocol driver one,
and remove unnecessary format check from my patch.

> So in block.c we could check if the format driver supports snapshots,
> and if it doesn't we try again with the underlying protocol. Not sure
> yet what we would do when both format and protocol do support snapshots
> (qcow2 on sheepdog/LVM/...), but that's a detail.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]