Re: [Qemu-devel] (iSCSI-)Readcache in Qemu?

[Peter Lieven]

Am 22.02.2013 um 13:15 schrieb Paolo Bonzini <address@hidden>:

> Il 22/02/2013 12:06, Stefan Hajnoczi ha scritto:
>> On Fri, Feb 22, 2013 at 08:51:48AM +0100, Peter Lieven wrote:
>>> is there any project or plans to integrate a readcache in qemu either for 
>>> iscsi or for the whole block layer?
>>> 
>>> I was thinking of 2 options:
>>> a) assign (up to) a fixed amount of ram for readcaching of a VMs disk I/O. 
>>> Without SG_IO this seems
>>> to be quite easy as there are only a handful of operations to intercept.
>>> b) add SSDs to a Node and allow a VM to use up to X MB of that SSD as 
>>> read-cache. This should still be
>>> a benefit if the storage for the VMs is on a NAS.
>>> 
>>> I would like to do that independent of the OS for 2 reasons. First with 
>>> iSCSI the OS
>>> is not involved. And second I would like to be able to add a memory limit 
>>> for the cache.
>> 
>> I'm not aware of such an effort.  In general QEMU tries to avoid caching
>> data because the host OS can already do it (if desired).
>> 
>> The Linux cgroups memory controller can limit file cache size for a
>> specific process or group of processes.
>> 
>>  http://www.kernel.org/doc/Documentation/cgroups/memory.txt
>> 
>> I suggest using the Linux iSCSI initiator together with cgroups to
>> achieve what you want.  Adding this functionality to QEMU will cost us
>> in complexity, data integrity worries, and code maintenance.
> 
> libiscsi has some nice advantages over the Linux iSCSI initiator.  One
> of them is that you don't need cache=none, but that mustn't count for
> Peter. :)  Others are that no privileges are needed to configure it,
> that it bypasses the "mandatory" partition scanning in the kernel, and
> that iscsi URIs are easier to use than udev stable paths.

Actually this is a great advantage as it always was a lot of hassle to prevent
udev from scanning iscsi devices that popped up and maintain all that
scripting around open-iscsi that was necessary. With libiscsi its much smarter.

As for caching I actually use write back if the flushes are supported by the 
drivers.
With libiscsi I know that a write command succeeds only if it has been 
successfully
transferred to the storage (which has battery backup).

My question was mainly arising from brain storming with some colleagues if a 
read
cache could help spare some read IOPS.

I was thinking if there is an already available library that could be used for 
this purpose (sth like
libmemcached)
It seems to me that without SG_IO the implementation of a cache in 
block/iscsi.c shouldn't
be that complicated.

Peter



> 
> Paolo
>