1. 30 11月, 2013 1 次提交
  2. 28 11月, 2013 1 次提交
  3. 29 10月, 2013 1 次提交
    • M
      qcow2: Flush image after creation · ba2ab2f2
      Max Reitz 提交于
      Opening the qcow2 image with BDRV_O_NO_FLUSH prevents any flushes during
      the image creation. This means that the image has not yet been flushed
      to disk when qemu-img create exits. This flush is delayed until the next
      operation on the image involving opening it without BDRV_O_NO_FLUSH and
      closing (or directly flushing) it. For large images and/or images with a
      small cluster size and preallocated metadata, this flush may take a
      significant amount of time and may occur unexpectedly.
      
      Reopening the image without BDRV_O_NO_FLUSH right before the end of
      qcow2_create2() results in hoisting the potentially costly flush into
      the image creation, which is expected to take some time (whereas
      successive image operations may be not).
      Signed-off-by: NMax Reitz <mreitz@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NBenoit Canet <benoit@irqsave.net>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      ba2ab2f2
  4. 24 10月, 2013 2 次提交
    • M
      qcow2: Unset zero_beyond_eof in save_vmstate · 6e13610a
      Max Reitz 提交于
      Saving the VM state is done using bdrv_pwrite. This function may perform
      a read-modify-write, which in this case results in data being read from
      beyond the end of the virtual disk. Since we are actually trying to
      access an area which is not a part of the virtual disk, zero_beyond_eof
      has to be set to false before performing the partial write, otherwise
      the VM state may become corrupted.
      Signed-off-by: NMax Reitz <mreitz@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      6e13610a
    • M
      qcow2: Restore total_sectors value in save_vmstate · eedff66f
      Max Reitz 提交于
      Since df2a6f29, bdrv_co_do_writev increases the total_sectors value of
      a growable block devices on writes after the current end. This leads to
      the virtual disk apparently growing in qcow2_save_vmstate, which in turn
      affects the disk size captured by the internal snapshot taken directly
      afterwards through e.g. the HMP savevm command. Such a "grown" snapshot
      cannot be loaded after reopening the qcow2 image, since its disk size
      differs from the actual virtual disk size (writing a VM state does not
      actually increase the virtual disk size).
      
      Fix this by restoring total_sectors at the end of qcow2_save_vmstate.
      Signed-off-by: NMax Reitz <mreitz@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      eedff66f
  5. 11 10月, 2013 8 次提交
  6. 26 9月, 2013 1 次提交
  7. 12 9月, 2013 9 次提交
  8. 06 9月, 2013 4 次提交
  9. 02 9月, 2013 1 次提交
  10. 30 8月, 2013 3 次提交
  11. 22 8月, 2013 1 次提交
    • A
      block: Introduce bs->zero_beyond_eof · 0d51b4de
      Asias He 提交于
      In 4146b46c42e0989cb5842e04d88ab6ccb1713a48 (block: Produce zeros when
      protocols reading beyond end of file), we break qemu-iotests ./check
      -qcow2 022. This happens because qcow2 temporarily sets ->growable = 1
      for vmstate accesses (which are stored beyond the end of regular image
      data).
      
      We introduce the bs->zero_beyond_eof to allow qcow2_load_vmstate() to
      disable ->zero_beyond_eof temporarily in addition to enable ->growable.
      
      [Since the broken patch "block: Produce zeros when protocols reading
      beyond end of file" has not been merged yet, I have applied this fix
      *first* and will then apply the next patch to keep the tree bisectable.
      -- Stefan]
      Suggested-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NAsias He <asias@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      0d51b4de
  12. 21 8月, 2013 1 次提交
  13. 27 7月, 2013 1 次提交
  14. 28 6月, 2013 1 次提交
    • P
      block: change default of .has_zero_init to 0 · 3ac21627
      Peter Lieven 提交于
      .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.
      
      vpc and vmdk also defaulted to 1 altough they support
      fixed respectively flat extends. this has to be addresses
      in separate patches. both formats as well as the mentioned
      ssh and gluster are turned to the default of 0 with this
      patch for safety.
      
      a similar problem with the wrong default existed for
      iscsi most likely because the driver developer did
      oversee the default value of 1.
      Signed-off-by: NPeter Lieven <pl@kamp.de>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      3ac21627
  15. 24 6月, 2013 3 次提交
  16. 14 5月, 2013 1 次提交
    • K
      qcow2: Catch some L1 table index overflows · 2cf7cfa1
      Kevin Wolf 提交于
      This catches the situation that is described in the bug report at
      https://bugs.launchpad.net/qemu/+bug/865518 and goes like this:
      
          $ qemu-img create -f qcow2 huge.qcow2 $((1024*1024))T
          Formatting 'huge.qcow2', fmt=qcow2 size=1152921504606846976 encryption=off cluster_size=65536 lazy_refcounts=off
          $ qemu-io /tmp/huge.qcow2 -c "write $((1024*1024*1024*1024*1024*1024 - 1024)) 512"
          Segmentation fault
      
      With this patch applied the segfault will be avoided, however the case
      will still fail, though gracefully:
      
          $ qemu-img create -f qcow2 /tmp/huge.qcow2 $((1024*1024))T
          Formatting 'huge.qcow2', fmt=qcow2 size=1152921504606846976 encryption=off cluster_size=65536 lazy_refcounts=off
          qemu-img: The image size is too large for file format 'qcow2'
      
      Note that even long before these overflow checks kick in, you get
      insanely high memory usage (up to INT_MAX * sizeof(uint64_t) = 16 GB for
      the L1 table), so with somewhat smaller image sizes you'll probably see
      qemu aborting for a failed g_malloc().
      
      If you need huge image sizes, you should increase the cluster size to
      the maximum of 2 MB in order to get higher limits.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      2cf7cfa1
  17. 22 4月, 2013 1 次提交