[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] block: change default of .has_zero_init to 0

From: Peter Lieven
Subject: Re: [Qemu-devel] [PATCH] block: change default of .has_zero_init to 0
Date: Fri, 28 Jun 2013 12:11:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

On 28.06.2013 12:09, Kevin Wolf wrote:
Am 28.06.2013 um 10:25 hat Peter Lieven geschrieben:
On 28.06.2013 10:20, Kevin Wolf wrote:
Am 28.06.2013 um 10:16 hat Peter Lieven geschrieben:
On 28.06.2013 10:06, Kevin Wolf wrote:
Am 27.06.2013 um 15:52 hat Peter Lieven geschrieben:
.has_zero_init defaults to 1 for all formats and protocols.

this is a dangerous default since this means that all
new added drivers need to manually overwrite it to 0 if
they do not ensure that a device is zero initialized
after bdrv_create().

if a driver needs to explicitly set this value to
1 its easier to verify the correctness in the review process.

during review of the existing drivers it turned out
that ssh and gluster had a wrong default of 1.
both protocols support host_devices as backend
which are not by default zero initialized. this
wrong assumption will lead to possible corruption
if qemu-img convert is used to write to such a backend.

a similar problem with the wrong default existed for
iscsi mose likely because the driver developer did
oversee the default value of 1.

Signed-off-by: Peter Lieven <address@hidden>
  block.c               |    8 +++++++-
  block/qcow.c          |    1 +
  block/qcow2.c         |    1 +
  block/qed.c           |    1 +
  block/raw-posix.c     |   10 +---------
  block/raw-win32.c     |    7 +------
  block/rbd.c           |    1 +
  block/sheepdog.c      |    1 +
  block/vdi.c           |    1 +
  block/vmdk.c          |    1 +
  include/block/block.h |    1 +
  11 files changed, 17 insertions(+), 16 deletions(-)
You forgot cow, which is also a simple case that can be handled in this
vpc is still easy, but a bit more complicated than a constant return 1,
because it depends on the subformat whether a new image will inherit the
has_zero_init property from the underlying storage or whether it always
produces zeros (for VHD_FIXED type images, it's basically raw + footer).
I'll send a separate patch for this.
shall I leave this to the new 0 default until your patch is ready?
Yes, please leave vpc alone. I guess my patch will be queued before
yours anyway. ;-)
once v2 is ready and noone has objections maybe you can put it in your queue? 
Sure. I'm going to send a pull request today, so it would be good to
have v2 of this patch soon. (Otherwise it would have to wait for
Stefan's pull request probably next Friday)
expect it in the next 60 minutes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]