From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Max Reitz <mreitz@redhat.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, den@openvz.org
Subject: Re: [PATCH v4 for-6.0? 0/3] qcow2: fix parallel rewrite and discard (rw-lock)
Date: Wed, 31 Mar 2021 09:23:47 +0300 [thread overview]
Message-ID: <129229b2-57e0-4ff9-5ffa-bdfcfba278bf@virtuozzo.com> (raw)
In-Reply-To: <61a00c13-3000-249e-8081-7b55ce5832bd@redhat.com>
30.03.2021 19:39, Max Reitz wrote:
>> ==
>>
>> OK, I think now that you didn't mean qcow2_alloc_clusters(). So, we are saying about only functions returning an offset to cluster with "guest data", not to any kind of host cluster. Than what you propose looks like this to me:
>>
>> - take my v5
>> - rename qcow2_inflight_writes_dec() to put_cluster_offset()
>> - call qcow2_inflight_writes_inc() from the three functions you mention
>
> Yes, I think so. Or you take the CoRwLock in those three functions, depending on which implementation we want.
CoRwLock brings one inconvenient feature: to pass ownership on the reference to coroutine (for example to task coroutine in qcow2_co_pwritev) we have to unlock the lock in original coroutine and lock in another, as CoRwLock doesn't support transferring to other coroutine. So we'll do put_cluster_offset() in qcow2_co_pwritev() and do get_cluster_offset() in qcow2_co_pwritev_task(). (and we must be sure that the second lock taken before releasing the first one). So in this case it probably better to keep direct CoRwLock interface, not shadowing it by get/put.
--
Best regards,
Vladimir
prev parent reply other threads:[~2021-03-31 6:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 10:08 [PATCH v4 0/3] qcow2: fix parallel rewrite and discard (rw-lock) Vladimir Sementsov-Ogievskiy
2021-03-19 10:08 ` [PATCH v4 1/3] qemu-io: add aio_discard Vladimir Sementsov-Ogievskiy
2021-03-19 10:08 ` [PATCH v4 2/3] iotests: add qcow2-discard-during-rewrite Vladimir Sementsov-Ogievskiy
2021-03-19 10:08 ` [PATCH v4 3/3] block/qcow2: introduce discard_rw_lock: fix discarding host clusters Vladimir Sementsov-Ogievskiy
2021-03-25 19:12 ` [PATCH v4 for-6.0? 0/3] qcow2: fix parallel rewrite and discard (rw-lock) Vladimir Sementsov-Ogievskiy
2021-03-30 9:49 ` Max Reitz
2021-03-30 10:51 ` Vladimir Sementsov-Ogievskiy
2021-03-30 12:51 ` Max Reitz
2021-03-30 13:25 ` Vladimir Sementsov-Ogievskiy
2021-03-30 16:39 ` Max Reitz
2021-03-30 18:33 ` Vladimir Sementsov-Ogievskiy
2021-03-31 6:23 ` Vladimir Sementsov-Ogievskiy [this message]
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=129229b2-57e0-4ff9-5ffa-bdfcfba278bf@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=den@openvz.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).