qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH 17/18] qemu-io: Add background write


From: Max Reitz
Subject: Re: [Qemu-block] [PATCH 17/18] qemu-io: Add background write
Date: Thu, 21 Sep 2017 17:03:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 2017-09-21 16:59, Fam Zheng wrote:
> On Thu, 09/21 16:40, Max Reitz wrote:
>> On 2017-09-19 10:03, Fam Zheng wrote:
>>> On Mon, 09/18 19:53, Max Reitz wrote:
>>>> On 2017-09-18 08:46, Fam Zheng wrote:
>>>>> On Wed, 09/13 20:19, Max Reitz wrote:
>>>>>> Add a new parameter -B to qemu-io's write command.  When used, qemu-io
>>>>>> will not wait for the result of the operation and instead execute it in
>>>>>> the background.
>>>>>
>>>>> Cannot aio_write be used for this purpose?
>>>>
>>>> Depends.  I have been trained to dislike *_aio_*, so that's probably the
>>>> initial reason why I didn't use it.
>>>>
>>>> Second, I'd have to fix aio_write before it can be used.  Currently,
>>>> this aborts:
>>>>
>>>> echo 'qemu-io drv0 "aio_write -P 0x11 0 64M"' \
>>>>     | x86_64-softmmu/qemu-system-x86_64 -monitor stdio \
>>>>           -blockdev node-name=drv0,driver=null-co
>>>>
>>>> because aio_write_done thinks it's a good idea to use qemu-io's
>>>> BlockBackend -- but when qemu-io is executed through the HMP, the
>>>> BlockBackend is only created for the duration of the qemu-io command
>>>> (unless there already is a BB).  So what I'd have to do is add a
>>>> blk_ref()/blk_unref() there, but for some reason I really don't like that.
>>>
>>> What is the reason? If it crashes it should be fixed anyway, I assume?
>>
>> Because the AIO CB (aio_write_done()) continues to use qemu-io's BB --
>> but in case of HMP's qemu-io, that is pretty much already gone once the
>> command is done.
> 
> I can see aio_{read,write}_done accesses BB for accounting, we can probably 
> skip
> this part altogether if issued from HMP (because the BB is gone). This way you
> don't need the blk_ref/unref pair.

Yep, and then it'd be functionally the same as this write -B, so that
sounds good.

Well, I fear that someone will have to rewrite it with coroutines
somewhere in the future anyway, but, er, well, not a problem for now!!1! :-)

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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