|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm |
Date: | Wed, 26 May 2010 11:44:43 +0300 |
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 |
On 05/25/2010 05:02 PM, Anthony Liguori wrote:
On 05/25/2010 08:57 AM, Avi Kivity wrote:On 05/25/2010 04:54 PM, Anthony Liguori wrote:On 05/25/2010 08:36 AM, Avi Kivity wrote:We'd need a kernel-level generic snapshot API for this eventually.or (2) implement BUSE to complement FUSE and CUSE to enable proper userspace block devices.Likely slow due do lots of copying. Also needs a snapshot API.The kernel could use splice.Still can't make guest memory appear in (A)BUSE process memory without either mmu tricks (vmsplice in reverse) or a copy. May be workable for an (A)BUSE driver that talks over a network, and thus can splice() its way out.splice() actually takes offset parameter so it may be possible to treat that offset parameter as a file offset. That would essentially allow you to implement a splice() based thread pool where splice() replaces preadv/pwritev.
Right. (note: need splicev() here)
It's not quite linux-aio, but it should take you pretty far. I think the main point is that the problem of allowing block plugins to qemu is the same as block plugins for the kernel. The kernel doesn't provide a stable interface (and we probably can't for the same reasons) and it's generally discourage from a code quality perspective.
The kernel does provide a stable interface for FUSE, and it could provide a stable interface for ABUSE. Why can the kernel support these and qemu can't support essentially the same thing?
That said, making an external program work well as a block backend is identical to making userspace block devices fast.
More or less, yes. -- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |