On 09/09/2010 08:02 PM, Anthony Liguori wrote:
On 09/09/2010 11:48 AM, Paolo Bonzini wrote:
On 09/09/2010 02:49 PM, Anthony Liguori wrote:
We should optimize for the future. That means a btrfs file system
and/or
enterprise storage.
So we should just implement a copy-on-read wrapper that generates a
sparse raw image and uses FIEMAP (or whatever it is called these
days) to test for the presence of extents. Then you let btrfs handle
everything else...
My position is that we'll need a sparse image format well into the
future because while btrfs may be ubiquitous as a file system, IRL,
people transfer images around all of the time through dumb transports
like HTTP and fat-formatted USB keys. A 100GB image with 1GB
allocated cannot explode to 100GB just because HTTP is a dump transport.
An 'Export' and 'Upload' buttons would do the job. For command line
users, compressing the image will remove the unallocated extents, as
will 'qemu-img convert -O qcow2'.
It's not as nice as having a sparse format, but on the other hand,
performance and data integrity will be better, as well as the excellent
snapshot support.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
