From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm Date: Tue, 25 May 2010 13:02:30 +0200 Message-ID: <4BFBAE46.5050801@redhat.com> References: <20100519192222.GD61706@ncolin.muc.de> <4BF5A9D2.5080609@codemonkey.ws> <4BF91937.2070801@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Blue Swirl , ceph-devel@vger.kernel.org, Christian Brunner , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: In-Reply-To: <4BF91937.2070801@redhat.com> Sender: ceph-devel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Am 23.05.2010 14:01, schrieb Avi Kivity: > On 05/21/2010 12:29 AM, Anthony Liguori wrote: >> >> I'd be more interested in enabling people to build these types of >> storage systems without touching qemu. >> >> Both sheepdog and ceph ultimately transmit I/O over a socket to a >> central daemon, right? > > That incurs an extra copy. > >> So could we not standardize a protocol for this that both sheepdog and >> ceph could implement? > > The protocol already exists, nbd. It doesn't support snapshotting etc. > but we could extend it. > > But IMO what's needed is a plugin API for the block layer. What would it buy us, apart from more downstreams and having to maintain a stable API and ABI? Hiding block drivers somewhere else doesn't make them stop existing, they just might not be properly integrated, but rather hacked in to fit that limited stable API. Kevin