All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Nefedov <anton.nefedov@virtuozzo.com>
To: Max Reitz <mreitz@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, kwolf@redhat.com, eblake@redhat.com,
	den@virtuozzo.com, berto@igalia.com
Subject: Re: [Qemu-devel] [PATCH v7 4/9] block: treat BDRV_REQ_ALLOCATE as serialising
Date: Tue, 30 Jan 2018 15:36:26 +0300	[thread overview]
Message-ID: <931c225d-7d0a-ea1e-59a9-d9f7a257274a@virtuozzo.com> (raw)
In-Reply-To: <e6a78f65-3be4-9c14-401c-ea7f1fd5fb9c@redhat.com>



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 subsequent requests to the area wait
>>    - ALLOCATE request itself must never wait if another request is in flight
>>      already. Return EAGAIN, let the caller reconsider.
>>
>> Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com>
>> Reviewed-by: Eric Blake <eblake@redhat.com>
>> ---
>>   block/io.c | 27 +++++++++++++++++++--------
>>   1 file changed, 19 insertions(+), 8 deletions(-)
> 
> The basic principle looks good to me.
> 
>> diff --git a/block/io.c b/block/io.c
>> index cf2f84c..4b0d34f 100644
>> --- a/block/io.c
>> +++ b/block/io.c
> 
> [...]
> 
>> @@ -1717,7 +1728,7 @@ int coroutine_fn bdrv_co_pwritev(BdrvChild *child,
>>           struct iovec head_iov;
>>   
>>           mark_request_serialising(&req, align);
>> -        wait_serialising_requests(&req);
>> +        wait_serialising_requests(&req, false);
> 
> What if someone calls bdrv_co_pwritev() with BDRV_REQ_ZERO_WRITE |
> BDRV_REQ_ALLOCATE?  

Either

     assert(!(qiov && (flags & BDRV_REQ_ALLOCATE)));

will fail or bdrv_co_do_zero_pwritev() will be used.

> .. Then this should do exactly the same as
> bdrv_co_do_zero_pwritev(), which it currently does not -- besides this
> serialization, this includes returning -ENOTSUP if there is a head or
> tail to write.
> 

Another question is if that assertion is ok.
In other words: should (qiov!=NULL && REQ_ALLOCATE) be a valid case?
e.g. with qiov filled with zeroes?

I'd rather document that not supported (and leave the assertion).

Actually, even (qiov!=NULL && REQ_ZERO_WRITE) looks kind of
unsupported/broken? Alignment code in bdrv_co_pwritev() zeroes out the
head and tail by passing the flag down bdrv_aligned_pwritev()

  reply	other threads:[~2018-01-30 12:36 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18 17:48 [Qemu-devel] [PATCH v7 0/9] qcow2: cluster space preallocation Anton Nefedov
2018-01-18 17:48 ` [Qemu-devel] [PATCH v7 1/9] mirror: inherit supported write/zero flags Anton Nefedov
2018-01-29 19:21   ` Max Reitz
2018-01-29 19:26     ` Eric Blake
2018-01-30 12:15       ` Anton Nefedov
2018-01-30 16:00         ` Eric Blake
2018-01-31 17:20         ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 2/9] blkverify: set " Anton Nefedov
2018-01-29 19:23   ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 3/9] block: introduce BDRV_REQ_ALLOCATE flag Anton Nefedov
2018-01-29 19:37   ` Max Reitz
2018-01-30 12:34     ` Anton Nefedov
2018-01-31 17:31       ` Max Reitz
2018-02-01 13:34         ` Anton Nefedov
2018-02-01 18:06           ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 4/9] block: treat BDRV_REQ_ALLOCATE as serialising Anton Nefedov
2018-01-29 19:48   ` Max Reitz
2018-01-30 12:36     ` Anton Nefedov [this message]
2018-01-31 17:35       ` Max Reitz
2018-01-31 15:11   ` Alberto Garcia
2018-01-31 17:11     ` Anton Nefedov
2018-02-01 14:01       ` Alberto Garcia
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 5/9] file-posix: support BDRV_REQ_ALLOCATE Anton Nefedov
2018-01-29 19:56   ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 6/9] block: support BDRV_REQ_ALLOCATE in passthrough drivers Anton Nefedov
2018-01-29 19:58   ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 7/9] qcow2: move is_zero() up Anton Nefedov
2018-01-29 19:59   ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 8/9] qcow2: skip writing zero buffers to empty COW areas Anton Nefedov
2018-01-29 20:28   ` Max Reitz
2018-01-30 14:23     ` Anton Nefedov
2018-01-31 17:40       ` Max Reitz
2018-01-31 18:32         ` Eric Blake
2018-01-31 18:35           ` Max Reitz
2018-01-31 18:43             ` Eric Blake
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 9/9] iotest 134: test cluster-misaligned encrypted write Anton Nefedov
2018-01-29 20:30   ` Max Reitz
2018-01-30 13:03   ` Alberto Garcia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=931c225d-7d0a-ea1e-59a9-d9f7a257274a@virtuozzo.com \
    --to=anton.nefedov@virtuozzo.com \
    --cc=berto@igalia.com \
    --cc=den@virtuozzo.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.