On Wed 31 Jan 2018 06:11:27 PM CET, Anton Nefedov wrote:
> On 31/1/2018 6:11 PM, Alberto Garcia wrote:
>> On Thu 18 Jan 2018 06:49:02 PM CET, Anton Nefedov wrote:
>>
>>> -static bool coroutine_fn wait_serialising_requests(BdrvTrackedRequest
>>> *self)
>>> +static bool coroutine_fn wait_serialisin
On 2018-01-30 13:36, Anton Nefedov wrote:
>
>
> On 29/1/2018 10:48 PM, Max Reitz wrote:
>> On 2018-01-18 18:49, Anton Nefedov wrote:
>>> The idea is that ALLOCATE requests may overlap with other requests.
>>> Reuse the existing block layer infrastructure for serialising requests.
>>> Use the foll
On 31/1/2018 6:11 PM, Alberto Garcia wrote:
On Thu 18 Jan 2018 06:49:02 PM CET, Anton Nefedov wrote:
-static bool coroutine_fn wait_serialising_requests(BdrvTrackedRequest *self)
+static bool coroutine_fn wait_serialising_requests(BdrvTrackedRequest *self,
+
On Thu 18 Jan 2018 06:49:02 PM CET, Anton Nefedov wrote:
> -static bool coroutine_fn wait_serialising_requests(BdrvTrackedRequest *self)
> +static bool coroutine_fn wait_serialising_requests(BdrvTrackedRequest *self,
> + bool nowait)
It's a bit co
On 29/1/2018 10:48 PM, Max Reitz wrote:
On 2018-01-18 18:49, Anton Nefedov wrote:
The idea is that ALLOCATE requests may overlap with other requests.
Reuse the existing block layer infrastructure for serialising requests.
Use the following approach:
- mark ALLOCATE serialising, so subsequen
On 2018-01-18 18:49, Anton Nefedov wrote:
> The idea is that ALLOCATE requests may overlap with other requests.
> Reuse the existing block layer infrastructure for serialising requests.
> Use the following approach:
> - mark ALLOCATE serialising, so subsequent requests to the area wait
> - ALLO
The idea is that ALLOCATE requests may overlap with other requests.
Reuse the existing block layer infrastructure for serialising requests.
Use the following approach:
- mark ALLOCATE serialising, so subsequent requests to the area wait
- ALLOCATE request itself must never wait if another reque