[Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"

From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	stefanha@gmail.com, mjt@tls.msk.ru, qemu-devel@nongnu.org,
	hch@lst.de
Subject: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"
Date: Wed, 25 Aug 2010 08:42:19 -0500	[thread overview]
Message-ID: <4C751DBB.8060101@codemonkey.ws> (raw)
In-Reply-To: <4C75195A.8050508@redhat.com>

On 08/25/2010 08:23 AM, Avi Kivity wrote:
>  On 08/25/2010 03:46 PM, Anthony Liguori wrote:
>>
>> If we had another disk format that only supported growth and metadata 
>> for a backing file, can you think of another failure scenario?
>
> btw, only supporting growth is a step backwards.  Currently 
> file-backed disks keep growing even the guest-used storage doesn't 
> grow, since once we allocate something we never release it.  But 
> eventually guests will start using TRIM or DISCARD or however it's 
> called, and then we can expose it and reclaim unused blocks.

You can do this in one of two ways.  You can do online compaction or you 
can maintain a free list.  Online compaction has an advantage because it 
does not require any operations in the fast path whereas a free list 
would require ordered metadata updates (must remove something from the 
first list before updating the l2 table) which implies a sync.

At a high level, I don't think online compaction requires any specific 
support from an image format.

Regards,

Anthony Liguori