qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_syn


From: Anthony Liguori
Subject: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"
Date: Wed, 25 Aug 2010 09:26:04 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

On 08/25/2010 09:18 AM, Christoph Hellwig wrote:
On Wed, Aug 25, 2010 at 04:23:38PM +0300, 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.
Together with file level snapshots Thin Provisioning support basically
makes qcow2 obsolete.

I think we'll always need a sparse image format. As long as people copy images to USB thumb drives containing vfat file systems or over dumb transports like HTTP, it will be necessary.

However, I agree that really advanced things like snapshotting is best done with a smart file system.

Regards,

Anthony Liguori

I already have a prototype implementation of scsi discard for qemu,
which together with the XFS extent size hints allows us to very
efficiently using growing and shrinking images on the bare filesystem.
XFS at this point doesn't have file-level snapshots, but I'm planning
to port the hole punhing and extent size hints to btrfs and maybe
ocfs2 which will give you all that.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]