On Tue, Jun 23, 2015 at 01:57:55PM -0400, John Snow wrote: > 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?
There is no out-of-channel for bs->file. The bs->file raw-posix image file includes the bs qcow2 sectors that hold the dirty bitmap. This is a corner case and I don't think any valid configuration would hit it. Stefan
pgpsZSbdIugtd.pgp
Description: PGP signature