On Fri, 09/06 11:57, Kevin Wolf wrote: > Am 06.09.2013 um 11:20 hat Fam Zheng geschrieben: > > On Wed, 09/04 11:39, Kevin Wolf wrote: > > > First of all, excuse any inconsistencies in the following mail. I wrote > > > it from top to bottom, and there was some thought process involved in > > > almost every paragraph... > > > > > > Am 04.09.2013 um 10:03 hat Stefan Hajnoczi geschrieben: > > > > On Tue, Sep 03, 2013 at 03:45:52PM +0200, Kevin Wolf wrote: > > > > > @@ -103,7 +107,11 @@ in the description of a field. > > > > > write to an image with unknown auto-clear > > > > > features if it > > > > > clears the respective bits from this field first. > > > > > > > > > > - Bits 0-63: Reserved (set to 0) > > > > > + Bit 0: Journal valid bit. This bit > > > > > indicates that the > > > > > + image contains a valid main journal > > > > > starting at > > > > > + journal_offset. > > > > > > > > Whether the journal is used can be determined from the journal_offset > > > > value (header length must be large enough and journal offset must be > > > > valid). > > > > > > > > Why do we need this autoclear bit? > > > > > > Hm, I introduced this one first and the journal dirty incompatible bit > > > later, perhaps it's unnecessary now. Let's check... > > > > > > The obvious thing we need to protect against is applying stale journal > > > data to an image that has been changed by an older version. As long as > > > the journal is clean, this can't happen, and the journal dirty bit will > > > ensure that the old version can only open the image if it is clean. > > > > > > However, what if we run 'qemu-img check -r leaks' with an old qemu-img > > > version? It will reclaim the clusters used by the journal, and if we > > > continue using the journal we'll corrupt whatever new data is there > > > now. > > > > > Why can old version qemu-img open the image with dirty journal in the first > > place? It's incompatible bit. > > This is about a clean journal. > Ah yes, I get it, thanks.
Fam