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
