qemu-devel
[Top][All Lists]
Advanced

[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: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU
Date: Wed, 12 May 2010 13:38:02 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

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.

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).

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.

Kevin



reply via email to

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