From: Kevin Wolf <kwolf@redhat.com>
To: Yury Kotov <yury-kotov@yandex-team.ru>
Cc: "open list:All patches CC here" <qemu-devel@nongnu.org>,
Juan Quintela <quintela@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] Question about bdrv_co_invalidate_cache
Date: Tue, 2 Jul 2019 10:07:35 +0200 [thread overview]
Message-ID: <20190702080735.GA7894@localhost.localdomain> (raw)
In-Reply-To: <1563421561999343@sas2-ae5b5c0d8595.qloud-c.yandex.net>
Am 01.07.2019 um 18:42 hat Yury Kotov geschrieben:
> Hi,
>
> I just want to clarify the purpose of bdrv_co_invalidate_cache callback.
> IIUC on of the purposes of this callback is to "activate" BDRV (opposite of the
> bdrv_inactivate callback) on migration end, right?
>
> E.g, if we have a custom BDRV which is backed by some network block storage with
> exclusive mount then on migration end bdrv_inactivate callback have to unmount
> this storage and bdrv_co_invalidate_cache have to mount it.
>
> I'm not sure because of the name of bdrv_co_invalidate_cache callback. It looks
> like something that can be called in very different context, not only migration
> (may be not now, but in the future).
>
> If there is another approach for my example, tell me about it, please.
> We have such custom BDRV with exclusive mount and want to realize migration
> support correctly.
Yes, you can consider bdrv_co_invalidate_cache/bdrv_co_inactivate a pair
of functions to activate/inactivate images. I think all of their callers
are related to migration currently, but it shouldn't make a difference
for you.
The name .bdrv_co_invalidate_cache hints at what usually needs to be
done on migration completion: Any previously read (meta)data must be
invalidated because the migration source (or more genereally: a second
process where the image was activated) may still have written to the
image.
Kevin
prev parent reply other threads:[~2019-07-02 8:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-01 16:42 [Qemu-devel] Question about bdrv_co_invalidate_cache Yury Kotov
2019-07-02 8:07 ` Kevin Wolf [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=20190702080735.GA7894@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=dgilbert@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=yury-kotov@yandex-team.ru \
/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).