Stefan,
--On 11 April 2013 11:25:48 +0200 Stefan Hajnoczi <stefa...@gmail.com>
wrote:
I'd like to experiment with adding persistent writeback cache to qemu.
The use case here is where non-local storage is used (e.g. rbd, ceph)
using the qemu drivers, together with a local cache as a file on
a much faster locally mounted device, for instance an SSD (possibly
replicated). This would I think give a similar performance boost to
using an rbd block device plus flashcache/dm-cache/bcache, but without
introducing all the context switches and limitations of having to
use real block devices. I appreciate it would need to be live migration
aware (worst case solution: flush and turn off caching during live
migrate), and ideally be capable of replaying a dirty writeback cache
in the event the host crashes.
Is there any support for this already? Has anyone worked on this before?
If not, would there be any interest in it?
I'm concerned about the complexity this would introduce in QEMU.
Therefore I'm a fan of using existing solutions like the Linux block
layer instead of reimplementing this stuff in Linux.
What concrete issues are there with using rbd plus
flashcache/dm-cache/bcache?
I'm not sure I understand the context switch problem since implementing
it in user space will still require system calls to do all the actual
cache I/O.
I failed to see your reply and got distracted from this. Apologies.
So several months later ...
The concrete problem here is that flashcache/dm-cache/bcache don't
work with the rbd (librbd) driver, as flashcache/dm-cache/bcache
cache access to block devices (in the host layer), and with rbd
(for instance) there is no access to a block device at all. block/rbd.c
simply calls librbd which calls librados etc.
So the context switches etc. I am avoiding are the ones that would
be introduced by using kernel rbd devices rather than librbd.
I had planned to introduce this as a sort of layer on top of any
existing block device handler; I believe they are layered at the
moment.
--
Alex Bligh