Am 09.04.2020 um 17:56 hat Eric Blake geschrieben:
> 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 shou
Am 09.04.2020 um 16:32 hat Eric Blake geschrieben:
> On 4/9/20 9:10 AM, Max Reitz wrote:
>
> > >
> > > What happens when an operation attempts to unmap things? Do we reject
> > > all unmap operations when data-file-raw is set (thus leaving a cluster
> > > marked as allocated at all times, if we
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 do
On 4/9/20 10:01 AM, Max Reitz wrote:
On 09.04.20 16:32, Eric Blake wrote:
On 4/9/20 9:10 AM, Max Reitz wrote:
What happens when an operation attempts to unmap things? Do we reject
all unmap operations when data-file-raw is set (thus leaving a cluster
marked as allocated at all times, if we c
On 09.04.20 16:32, Eric Blake wrote:
> On 4/9/20 9:10 AM, Max Reitz wrote:
>
>>>
>>> What happens when an operation attempts to unmap things? Do we reject
>>> all unmap operations when data-file-raw is set (thus leaving a cluster
>>> marked as allocated at all times, if we can first guarantee tha
On 4/9/20 9:10 AM, Max Reitz wrote:
What happens when an operation attempts to unmap things? Do we reject
all unmap operations when data-file-raw is set (thus leaving a cluster
marked as allocated at all times, if we can first guarantee that
preallocation set things up that way)?
No, unmap op
On 09.04.20 15:47, Eric Blake wrote:
> On 4/9/20 8:42 AM, Eric Blake wrote:
>
I'd argue that requiring the user to pre-zero the raw data file is
undesirable; and that we should instead fix our code to not report the
image as reading all zeroes when creating with data_file_raw=on.
>>
On 4/9/20 8:42 AM, Eric Blake wrote:
I'd argue that requiring the user to pre-zero the raw data file is
undesirable; and that we should instead fix our code to not report the
image as reading all zeroes when creating with data_file_raw=on.
OK. I think that could be achieved by just enforcing
On 4/9/20 8:05 AM, Max Reitz wrote:
$ sudo ./qemu-img create -f qcow2 -o \
data_file=/dev/loop0,data_file_raw=on foo.qcow2 64M
[...]
$ sudo ./qemu-io -c 'read -P 0 0 64M' foo.qcow2
read 67108864/67108864 bytes at offset 0
64 MiB, 1 ops; 00.00 sec (25.036 GiB/sec and 400.5751 ops/sec)
Th
On 07.04.20 00:22, Eric Blake wrote:
> On 2/17/20 10:56 AM, Max Reitz wrote:
>> Hi,
>>
>> AFAIU, external data files with data_file_raw=on are supposed to return
>> the same data as the qcow2 file when read. But we still use the qcow2
>> metadata structures (which are by default initialized to “ev
On 2/17/20 10:56 AM, Max Reitz wrote:
Hi,
AFAIU, external data files with data_file_raw=on are supposed to return
the same data as the qcow2 file when read. But we still use the qcow2
metadata structures (which are by default initialized to “everything
unallocated”), even though we never ensure
Hi,
AFAIU, external data files with data_file_raw=on are supposed to return
the same data as the qcow2 file when read. But we still use the qcow2
metadata structures (which are by default initialized to “everything
unallocated”), even though we never ensure that the external data file
is zero, to
12 matches
Mail list logo
