On 06/15/2015 10:42 AM, Stefan Hajnoczi wrote: > On Fri, Jun 12, 2015 at 03:02:33PM -0400, John Snow wrote: >> >> >> On 06/10/2015 10:30 AM, Stefan Hajnoczi wrote: >>> On Mon, Jun 08, 2015 at 06:21:20PM +0300, Vladimir Sementsov-Ogievskiy >>> wrote: >>> >>> I noticed a corner case, it's probably not a problem in practice: >>> >>> Since the dirty bitmap is stored with the help of a BlockDriverState >>> (and its bs->file), it's possible that writing the bitmap will cause >>> bits in the bitmap to be dirtied! >>> >> >> But since it's metadata and not stored within a disk sector, can this >> actually happen? Do you have an example of a scenario where this might >> come up? > > The persistent dirty bitmap for bs->file is storeed in the qcow2 BDS. > This results in recursion. > > This is a misconfiguration but I just want to understand what happens > when someone does this by mistake. > > Stefan >
I still don't follow you, actually. The dirty bitmap only tracks changed virtual disk sectors, not actual file sectors, right? Writing a bitmap that describes foo.qcow2 to foo.qcow2 won't dirty bitmaps, it's an out-of-channel write as far as the bitmap is concerned. Right? Am I fatally misunderstanding the situation?
