Re: qcow2: Zero-initialization of external data files

From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>, Qemu-block <qemu-block@nongnu.org>,
	Kevin Wolf <kwolf@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: qcow2: Zero-initialization of external data files
Date: Thu, 9 Apr 2020 10:56:47 -0500	[thread overview]
Message-ID: <8c7ba1fe-6995-2465-789b-29212d07bf23@redhat.com> (raw)
In-Reply-To: <5a8099d6-3885-2bfe-f85a-477c5cc76a45@redhat.com>

On 4/9/20 10:46 AM, Eric Blake wrote:

>>> We don't support concurrent modification. But if the guest is running
>>> and unmaps things, then shuts off, then we edit the raw file offline,
>>> then we restart the guest, the guest should see the results of those
>>> offline edits.
>>
>> Should it?  The specification doesn’t say anything about that.
>>
>> In fact, I think we have always said we explicitly discourage that
>> because this might lead to outdated metadata; even though we usually
>> meant “dirty bitmaps” by that.
> 
> Hmm.  Kevin, I'd really like your opinion here.  The point of the 
> raw-external-data flag is to state that "qemu MUST ensure that whatever 
> is done to this image while the guest is running is reflected through to 
> the raw file, so that after the guest stops, the raw file alone is still 
> viable to see what the guest saw".  But as you say, there's a difference 
> between "the raw file will read what the guest saw" and "we can now edit 
> the raw file without regards to the qcow2 wrapper but later reuse of the 
> qcow2 wrapper won't be corrupted by those edits".

Another random thought: Should we add a header extension that records 
the timestamps of an external data file?  That way, if the timestamps of 
the file have changed from what we recorded in our optional header, then 
we can flag to the user that our metadata may be stale because of what 
appears to be external edits.  But that's not always going to save us - 
timestamps on a block device don't behave the same as timestamps on a 
POSIX file, and just because timestamps change (such as when copying a 
file from one place to another) does not imply that contents have 
changed.  My personal take - unless adding such a header can definitely 
add safety, it may not be worth the cost of complicating the standard - 
this was more just documenting an idea I had even if we don't choose to 
pursue it.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org