On 09/15/2010 04:01 PM, Michael S. Tsirkin wrote:
On Mon, Sep 06, 2010 at 11:04:38AM +0100, Stefan Hajnoczi wrote:
The format supports sparse disk images. It does not rely on the host
filesystem holes feature, making it a good choice for sparse disk images
that need to be transferred over c
On Mon, Sep 06, 2010 at 11:04:38AM +0100, Stefan Hajnoczi wrote:
> The format supports sparse disk images. It does not rely on the host
> filesystem holes feature, making it a good choice for sparse disk images
> that need to be transferred over channels where holes are not supported.
Are these s
On 09/06/2010 05:45 AM, Anthony Liguori wrote:
>>
>> Before inventing yet another image format, you certainly have checked
>> the existing ones.
>
> Obviously, yes.
>
> Here are the issues:
>
> cow.c: it's cow of an otherwise sparse file. An important reason for
> implementing a format is the
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 gen
On Thu, Sep 09, 2010 at 12:02:26PM -0500, Anthony Liguori wrote:
> 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-
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 wha
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 th
On 09/06/2010 09:10 AM, Kevin Wolf wrote:
If you implement a subset of functionality for an existing on-disk
format, I think you damage user's expectations.
I don't really buy that implementing compression/encryption wouldn't
have been possible if it was the only problem. Of course, if y
Am 06.09.2010 14:57, schrieb Anthony Liguori:
> On 09/06/2010 07:40 AM, Stefan Hajnoczi wrote:
>> On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf wrote:
>>
>>> Am 06.09.2010 12:04, schrieb Stefan Hajnoczi:
>>>
QEMU Enhanced Disk format is a disk image format that forgoes features
f
On Mon, Sep 6, 2010 at 1:57 PM, Anthony Liguori wrote:
> On 09/06/2010 07:40 AM, Stefan Hajnoczi wrote:
>>
>> On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf wrote:
>>
>>>
>>> Am 06.09.2010 12:04, schrieb Stefan Hajnoczi:
>>>
QEMU Enhanced Disk format is a disk image format that forgoes fea
On 09/06/2010 07:40 AM, Stefan Hajnoczi wrote:
On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf wrote:
Am 06.09.2010 12:04, schrieb Stefan Hajnoczi:
QEMU Enhanced Disk format is a disk image format that forgoes features
found in qcow2 in favor of better levels of performance and data
inte
On 09/06/2010 05:27 AM, Kevin Wolf wrote:
Okay, so before I actually look at the patch longer than a couple of
seconds let me just ask the obvious question...
Before inventing yet another image format, you certainly have checked
the existing ones.
Obviously, yes.
Here are the issues:
cow.c:
On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf wrote:
> Am 06.09.2010 12:04, schrieb Stefan Hajnoczi:
>> QEMU Enhanced Disk format is a disk image format that forgoes features
>> found in qcow2 in favor of better levels of performance and data
>> integrity. Due to its simpler on-disk layout, it is p
Am 06.09.2010 12:04, schrieb Stefan Hajnoczi:
> QEMU Enhanced Disk format is a disk image format that forgoes features
> found in qcow2 in favor of better levels of performance and data
> integrity. Due to its simpler on-disk layout, it is possible to safely
> perform metadata updates more efficie
14 matches
Mail list logo
