qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] (iSCSI-)Readcache in Qemu?
Date: Fri, 22 Feb 2013 13:15:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]