Re: [Qemu-devel] Adding a persistent writeback cache to qemu

[Alex Bligh]

Stefan,

--On 11 April 2013 11:25:48 +0200 Stefan Hajnoczi <address@hidden> 
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