On Mon, Nov 12, 2018 at 5:26 PM Max Reitz <mre...@redhat.com> wrote: > On 12.11.18 00:36, Nir Soffer wrote: > > On Mon, Nov 12, 2018 at 12:25 AM Max Reitz <mre...@redhat.com > > <mailto:mre...@redhat.com>> wrote: > > > > This is what I’ve taken from two or three BoF-like get-togethers on > > blocky things. Amendments are more than welcome, of course. > > > > ... > > > > Bitmaps > > > > ======= > > > > (Got this section from sneaking into a BoF I wasn’t invited to. Oh > > well. Won’t hurt to include them here.) > > > > Currently, when dirty bitmaps are loaded, all IN_USE bitmaps are just > > not loaded at all and completely ignored. That isn’t correct, > though, > > they should either still be loaded (and automatically treated and > > written back as fully dirty), or at least qemu-img check should > > “repair” them (i.e. fully dirtying them). > > > > > > I'm not sure making bitmaps dirty is better. > > > > When bitmap is marked IN_USE, it means that we cannot use it for > > backup. Deleting the bitmap or making it as bad so it cannot be used > > for the next backup is the same. Making the bitmap as dirty will full > > the management layer that everything was fine when the next backup > > includes the entire disk. It is better to cause the next backup to fail > > in a verbose way, since the backup software can recover by doing > > a full backup. > > But making the dirty bitmap fully dirty will automatically enforce a > full backup. >
True, but is also hide the fact that we lost the bitmap. I think we should start with the simple way of making it fail and let the rest of the stack fallback to full backup. > Sometimes qemu (running in a mode as bare as possible) is better than > > using qemu-img convert, for instance. It gives you more control > > (through QMP; you get e.g. better progress reporting), you get all of > > the mirror optimizations (we do have optimizations for convert, too, > > but whether it’s any good to write the same (or different?) > > optimizations twice is another question), and you get a common > > interface for everything (online and offline). > > Note that besides a bare qemu we’ve also always wanted to convert as > > many qemu-img operations into frontends for block jobs as possible. > > We have only done this for commit, however, even though convert > looked > > like basically the ideal target. It was just too hard with too > little > > apparent gain, like always (and convert supports additional features > > like concatenation which we don’t have in the runtime block layer > > yet). > > > > > > I'm not sure it is better to run qemu and use qemu-img as thin wrapper > > over qmp. > > > > For example, management system may ascociate qemu-img > > with a sanlock lease, and sanlock may try to terminate qemu-img when > > a lease is invalidated. In this case sanlock will succeed while qemu is > till > > accessing storage it should not access. > > ... > > The point was not to run two processes, but to link the necessary bits > of qemu into qemu-img and then use them inside the single qemu-img > process itself. As hinted at above, we've been doing this for qemu-img > commit for quite some time; that command actually runs a block job under > the hood (inside of qemu-img). > Sounds great. Nir
