qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/3] block: blk_co_pcache


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH 0/3] block: blk_co_pcache
Date: Mon, 17 Jun 2019 11:20:42 +0000

06.06.2019 17:07, Vladimir Sementsov-Ogievskiy wrote:
> 06.06.2019 16:55, Eric Blake wrote:
>> On 6/6/19 8:48 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> Here is small new io API: blk_co_pcache, which does copy-on-read without
>>> extra buffer for read data. This means that only parts that needs COR
>>> will be actually read and only corresponding buffers allocated, no more.
>>>
>>> This allows to improve a bit block-stream and NBD_CMD_CACHE
>>
>> I'd really like to see qemu-io gain access to calling this command, so
>> that we can add iotests coverage of this new feature. Note that the
>> in-development libnbd
>> (https://github.com/libguestfs/libnbd/commits/master) is also usable as
>> an NBD client that can drive NBD_CMD_CACHE, although it's still new
>> enough that we probably don't want to rely on it being available yet.
>>
> 
> Hmm, don't you think that blk_co_pcache sends NBD_CMD_CACHE if called on nbd 
> driver?
> I didn't implement it. But may be I should..
> 
> May aim was only to avoid extra allocation and unnecessary reads. But if we 
> implement
> full-featured io request, what should it do?
> 
> On qcow2 with backing it should pull data from backing to top, like in 
> copy-on-read.
> And for nbd it will send NBD_CMD_CACHE?
> These semantics seems different, but why not?
> 

Any opinions here? Should I resend or could we use it as a first step, not 
touching
external API but improving things a little bit?


-- 
Best regards,
Vladimir

reply via email to

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