On Wed, Jun 10, 2020 at 7:31 PM Kevin Wolf wrote:
> Am 10.06.2020 um 17:26 hat Sam Eiderman geschrieben:
> > Thanks for the clarification Kevin,
> >
> > Well first I want to discuss unallocated blocks.
> > From my understanding operating systems do not rely on disks to be
> > zero initialized, on
On Wednesday, 2020-06-10 at 11:21:27 -05, Eric Blake wrote:
> On 6/10/20 10:57 AM, David Edmondson wrote:
>> On Wednesday, 2020-06-10 at 10:48:52 -05, Eric Blake wrote:
>>
>>> On 6/10/20 10:42 AM, David Edmondson wrote:
On Wednesday, 2020-06-10 at 18:29:33 +03, Sam Eiderman wrote:
>
Am 10.06.2020 um 17:26 hat Sam Eiderman geschrieben:
> Thanks for the clarification Kevin,
>
> Well first I want to discuss unallocated blocks.
> From my understanding operating systems do not rely on disks to be
> zero initialized, on the contrary, physical disks usually contain
> garbage.
> So a
On 6/10/20 10:57 AM, David Edmondson wrote:
On Wednesday, 2020-06-10 at 10:48:52 -05, Eric Blake wrote:
On 6/10/20 10:42 AM, David Edmondson wrote:
On Wednesday, 2020-06-10 at 18:29:33 +03, Sam Eiderman wrote:
Excuse me,
Vladimir already pointed out in the first comment that it will skip
wr
On Wednesday, 2020-06-10 at 10:48:52 -05, Eric Blake wrote:
> On 6/10/20 10:42 AM, David Edmondson wrote:
>> On Wednesday, 2020-06-10 at 18:29:33 +03, Sam Eiderman wrote:
>>
>>> Excuse me,
>>>
>>> Vladimir already pointed out in the first comment that it will skip
>>> writing real zeroes later.
>
On 6/10/20 10:42 AM, David Edmondson wrote:
On Wednesday, 2020-06-10 at 18:29:33 +03, Sam Eiderman wrote:
Excuse me,
Vladimir already pointed out in the first comment that it will skip
writing real zeroes later.
Right. That's why you want something like "--no-need-to-zero-initialise"
(the na
Ok great, thanks for making it clear.
On Wed, Jun 10, 2020 at 6:42 PM David Edmondson wrote:
>
> On Wednesday, 2020-06-10 at 18:29:33 +03, Sam Eiderman wrote:
>
> > Excuse me,
> >
> > Vladimir already pointed out in the first comment that it will skip
> > writing real zeroes later.
>
> Right. Tha
On Wednesday, 2020-06-10 at 18:29:33 +03, Sam Eiderman wrote:
> Excuse me,
>
> Vladimir already pointed out in the first comment that it will skip
> writing real zeroes later.
Right. That's why you want something like "--no-need-to-zero-initialise"
(the name keeps getting longer!), which would st
Excuse me,
Vladimir already pointed out in the first comment that it will skip
writing real zeroes later.
Sam
On Wed, Jun 10, 2020 at 6:26 PM Sam Eiderman wrote:
>
> Thanks for the clarification Kevin,
>
> Well first I want to discuss unallocated blocks.
> From my understanding operating system
Thanks for the clarification Kevin,
Well first I want to discuss unallocated blocks.
>From my understanding operating systems do not rely on disks to be
zero initialized, on the contrary, physical disks usually contain
garbage.
So an unallocated block should never be treated as zero by any real
wo
Am 10.06.2020 um 14:19 hat Sam Eiderman geschrieben:
> Thanks David,
>
> Yes, I imaging the following use case:
>
> disk.vmdk is a 50 GB disk that contains 12 MB binary of zeroes in its
> beginning.
> /dev/sda is a raw disk containing garbage
>
> I invoke:
> qemu-img convert disk.vmdk -O raw /d
10.06.2020 15:19, Sam Eiderman wrote:
Thanks David,
Yes, I imaging the following use case:
disk.vmdk is a 50 GB disk that contains 12 MB binary of zeroes in its beginning.
/dev/sda is a raw disk containing garbage
I invoke:
qemu-img convert disk.vmdk -O raw /dev/sda
Required output:
The first
Thanks David,
Yes, I imaging the following use case:
disk.vmdk is a 50 GB disk that contains 12 MB binary of zeroes in its beginning.
/dev/sda is a raw disk containing garbage
I invoke:
qemu-img convert disk.vmdk -O raw /dev/sda
Required output:
The first 12 MB of /dev/sda contain zeros, the re
On Wednesday, 2020-06-10 at 08:28:29 +03, Sam Eiderman wrote:
> Hi,
>
> 168468fe19c8 ("qemu-img: Add --target-is-zero to convert") has added a
> nice functionality for cloud scenarios:
>
> * Create a virtual disk
> * Convert a sparse image (qcow2, vmdk) to the virtual disk using
> --target-is-zero
I see,
I thought qemu-img (by default) checks the virtual size of the disk
before starting to copy allocated data, zeroes out all of the virtual
size (slowly) and then writes all the allocated data except for
zeroes.
But from what I understand now, qemu-img finds that the target is raw
and can no
Am 10.06.2020 um 08:28 hat Sam Eiderman geschrieben:
> Hi,
>
> My target format is a Persistent Disk on GCP.
> https://cloud.google.com/persistent-disk
>
> And my use case is converting VMDKs to PDs so I'm just using qemu-img
> for the conversion (not using qemu as a hypervisor).
>
> Luckily PDs
Hi,
My target format is a Persistent Disk on GCP.
https://cloud.google.com/persistent-disk
And my use case is converting VMDKs to PDs so I'm just using qemu-img
for the conversion (not using qemu as a hypervisor).
Luckily PDs are zeroed out when allocated but I was asking to
understand the restr
Hi Sam!
10.06.2020 08:28, Sam Eiderman wrote:
Hi,
168468fe19c8 ("qemu-img: Add --target-is-zero to convert") has added a
nice functionality for cloud scenarios:
* Create a virtual disk
What is the format of your target?
* Convert a sparse image (qcow2, vmdk) to the virtual disk using
--tar
Hi,
168468fe19c8 ("qemu-img: Add --target-is-zero to convert") has added a
nice functionality for cloud scenarios:
* Create a virtual disk
* Convert a sparse image (qcow2, vmdk) to the virtual disk using
--target-is-zero
* Use the virtual disk
This saves many unnecessary writes - a qcow2 with 1M
19 matches
Mail list logo
