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 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
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
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
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.
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
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
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
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
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
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
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
>
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
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
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
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
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
19 matches
Mail list logo
