On 04.11.19 12:21, Max Reitz wrote: > On 01.11.19 16:42, John Snow wrote: >> Hi, in one of my infamously unreadable and long status emails, I >> mentioned possibly wanting to copy allocation data into bitmaps as a way >> to enable users to create (external) snapshots from outside of the >> libvirt/qemu context. >> >> (That is: to repair checkpoints in libvirt after a user extended the >> backing chain themselves, you want to restore bitmap information for >> that node. Conveniently, this information IS the allocation map, so we >> can do this.) >> >> It came up at KVM Forum that we probably do want this, because oVirt >> likes the idea of being able to manipulate these chains from outside of >> libvirt/qemu. >> >> Denis suggested that instead of a new command, we can create a special >> name -- maybe "#ALLOCATED" or something similar that can never be >> allocated as a user-defined bitmap name -- as a special source for the >> merge command. >> >> You'd issue a merge from "#ALLOCATED" to "myBitmap0" to copy the current >> allocation data into "myBitmap0", for instance. > > Sounds fun, but is there actually any use for this if the only purpose > is to work as a source for merge? > > I mean, it would be interesting if it worked exactly like a perma-RO > pseudo-bitmap that whenever you try to get data from it performs a > block-status call. But as you say, that would probably be too slow, and > it would take a lot of code modifications, so I wonder if there is > actually any purpose for this. > >> Some thoughts: >> >> - The only commands where this pseudo-bitmap makes sense is merge. >> enable/disable/remove/clear/add don't make sense here. >> >> - This pseudo bitmap might make sense for backup, but it's not needed; >> you can just merge into an empty/enabled bitmap and then use that. >> >> - Creating an allocation bitmap on-the-fly is probably not possible >> directly in the merge command, because the disk status calls might take >> too long... >> >> Hm, actually, I'm not sure how to solve that one. Merge would need to >> become a job (or an async QMP command?) or we'd need to keep an >> allocation bitmap object around and in-sync. I don't really want to do >> either, so maybe I'm missing an obvious/better solution. > > All of what you wrote in this mail makes me think it would make much > more sense to just add a “block-dirty-bitmap-create-from” job with an > enum of targets. (One of which would be “allocated-blocks”.)
I forgot to add that of course the advantage of a pseudo-bitmap would be that it’s always up to date, but as you said, it would be slow to query (and it might even yield, which isn’t what callers expect) and at least for block allocation, it seems unnecessary to me (because writes will keep the new bitmap created from allocated-blocks up-to-date). Max
signature.asc
Description: OpenPGP digital signature
