07.02.2020 18:12, Max Reitz wrote:
On 07.02.20 15:57, Eric Blake wrote:
On 2/7/20 8:41 AM, Max Reitz wrote:
I could imagine a user creating a qcow2 image on some block device with
preallocation where we cannot verify that the result will be zero. But
they want qemu not to zero the device, so
On 07.02.20 16:16, Vladimir Sementsov-Ogievskiy wrote:
> 07.02.2020 18:03, Max Reitz wrote:
>> On 07.02.20 15:53, Vladimir Sementsov-Ogievskiy wrote:
>>> 07.02.2020 17:41, Max Reitz wrote:
On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
> 07.02.2020 13:33, Max Reitz wrote:
>> On
On 07.02.20 15:57, Eric Blake wrote:
> On 2/7/20 8:41 AM, Max Reitz wrote:
>
I could imagine a user creating a qcow2 image on some block device with
preallocation where we cannot verify that the result will be zero. But
they want qemu not to zero the device, so they would specify
>
07.02.2020 18:03, Max Reitz wrote:
On 07.02.20 15:53, Vladimir Sementsov-Ogievskiy wrote:
07.02.2020 17:41, Max Reitz wrote:
On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
07.02.2020 13:33, Max Reitz wrote:
On 04.02.20 15:23, Eric Blake wrote:
On 2/4/20 7:59 AM, Vladimir Sementsov-Og
On 07.02.20 15:53, Vladimir Sementsov-Ogievskiy wrote:
> 07.02.2020 17:41, Max Reitz wrote:
>> On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
>>> 07.02.2020 13:33, Max Reitz wrote:
On 04.02.20 15:23, Eric Blake wrote:
> On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
>
>
On 2/7/20 8:41 AM, Max Reitz wrote:
I could imagine a user creating a qcow2 image on some block device with
preallocation where we cannot verify that the result will be zero. But
they want qemu not to zero the device, so they would specify
--target-is-zero.
If user create image, setting --tar
On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
> 07.02.2020 13:33, Max Reitz wrote:
>> On 04.02.20 15:23, Eric Blake wrote:
>>> On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>
> I understand that it is safer to have restrictions now and lift them
> later, than to allow us
07.02.2020 17:41, Max Reitz wrote:
On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
07.02.2020 13:33, Max Reitz wrote:
On 04.02.20 15:23, Eric Blake wrote:
On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
I understand that it is safer to have restrictions now and lift them
later,
07.02.2020 13:33, Max Reitz wrote:
On 04.02.20 15:23, Eric Blake wrote:
On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
I understand that it is safer to have restrictions now and lift them
later, than to allow use of the option at any time and leave room for
the user to shoot themselves
On 04.02.20 15:23, Eric Blake wrote:
> On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
>
>>> I understand that it is safer to have restrictions now and lift them
>>> later, than to allow use of the option at any time and leave room for
>>> the user to shoot themselves in the foot with no wa
On 2/4/20 8:21 AM, David Edmondson wrote:
On Tuesday, 2020-02-04 at 07:31:52 -06, Eric Blake wrote:
On 2/4/20 3:52 AM, David Edmondson wrote:
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
'filled with
On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
I understand that it is safer to have restrictions now and lift them
later, than to allow use of the option at any time and leave room for
the user to shoot themselves in the foot with no way to add safety
later. The argument against no b
On Tuesday, 2020-02-04 at 16:59:39 +03, Vladimir Sementsov-Ogievskiy wrote:
> 04.02.2020 12:52, David Edmondson wrote:
>> In many cases the target of a convert operation is a newly provisioned
>> target that the user knows is blank (filled with zeroes). In this
>> situation there is no requirement
On Tuesday, 2020-02-04 at 07:31:52 -06, Eric Blake wrote:
> On 2/4/20 3:52 AM, David Edmondson wrote:
>> In many cases the target of a convert operation is a newly provisioned
>> target that the user knows is blank (filled with zeroes). In this
>
> 'filled with zeroes' is accurate for a preallocat
04.02.2020 16:31, Eric Blake wrote:
On 2/4/20 3:52 AM, David Edmondson wrote:
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
'filled with zeroes' is accurate for a preallocated image, but reads awkwardly
04.02.2020 12:52, David Edmondson wrote:
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
situation there is no requirement for qemu-img to wastefully zero out
the entire device.
Add a new option, --target-is
On 2/4/20 3:52 AM, David Edmondson wrote:
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
'filled with zeroes' is accurate for a preallocated image, but reads
awkwardly for a sparse image; it might be bett
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this
situation there is no requirement for qemu-img to wastefully zero out
the entire device.
Add a new option, --target-is-zero, allowing the user to indicate that
a
18 matches
Mail list logo
