1. 05 4月, 2012 5 次提交
  2. 12 3月, 2012 1 次提交
    • S
      block: handle -EBUSY in bdrv_commit_all() · e8877497
      Stefan Hajnoczi 提交于
      Monitor operations that manipulate image files must not execute while a
      background job (like image streaming) is in progress.  This prevents
      corruptions from happening when two pieces of code are manipulating the
      image file without knowledge of each other.
      
      The monitor "commit" command raises QERR_DEVICE_IN_USE when
      bdrv_commit() returns -EBUSY but "commit all" has no error handling.
      This is easy to fix, although note that we do not deliver a detailed
      error about which device was busy in the "commit all" case.
      Suggested-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      e8877497
  3. 29 2月, 2012 3 次提交
  4. 23 2月, 2012 3 次提交
  5. 09 2月, 2012 2 次提交
    • S
      block: perform zero-detection during copy-on-read · 79c053bd
      Stefan Hajnoczi 提交于
      Copy-on-Read populates the image file with data read from a backing
      image.  In order to avoid bloating the image file when all zeroes are
      read we should scan the buffer and perform an optimized zero write
      operation.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      79c053bd
    • S
      block: add .bdrv_co_write_zeroes() interface · f08f2dda
      Stefan Hajnoczi 提交于
      The ability to zero regions of an image file is a useful primitive for
      higher-level features such as image streaming or zero write detection.
      
      Image formats may support an optimized metadata representation instead
      of writing zeroes into the image file.  This allows zero writes to be
      potentially faster than regular write operations and also preserve
      sparseness of the image file.
      
      The .bdrv_co_write_zeroes() interface should be implemented by block
      drivers that wish to provide efficient zeroing.
      
      Note that this operation is different from the discard operation, which
      may leave the contents of the region indeterminate.  That means
      discarded blocks are not guaranteed to contain zeroes and may contain
      junk data instead.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      f08f2dda
  6. 26 1月, 2012 4 次提交
  7. 15 12月, 2011 3 次提交
  8. 05 12月, 2011 15 次提交
  9. 22 11月, 2011 1 次提交
    • A
      block: allow migration to work with image files (v3) · 0f15423c
      Anthony Liguori 提交于
      Image files have two types of data: immutable data that describes things like
      image size, backing files, etc. and mutable data that includes offset and
      reference count tables.
      
      Today, image formats aggressively cache mutable data to improve performance.  In
      some cases, this happens before a guest even starts.  When dealing with live
      migration, since a file is open on two machines, the caching of meta data can
      lead to data corruption.
      
      This patch addresses this by introducing a mechanism to invalidate any cached
      mutable data a block driver may have which is then used by the live migration
      code.
      
      NB, this still requires coherent shared storage.  Addressing migration without
      coherent shared storage (i.e. NFS) requires additional work.
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      0f15423c
  10. 11 11月, 2011 3 次提交
    • K
      block: Make cache=unsafe flush to the OS · ca716364
      Kevin Wolf 提交于
      cache=unsafe completely ignored bdrv_flush, because flushing the host disk
      costs a lot of performance. However, this means that qcow2 images (and
      potentially any other format) can lose data even after the guest has issued a
      flush if the qemu process crashes/is killed. In case of a host crash, data loss
      is certainly expected with cache=unsafe, but if just the qemu process dies this
      is a bit too unsafe.
      
      Now that we have two separate flush functions, we can choose to flush
      everythign to the OS, but don't enforce that it's physically written to the
      disk.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      ca716364
    • K
      block: Introduce bdrv_co_flush_to_os · eb489bb1
      Kevin Wolf 提交于
      qcow2 has a writeback metadata cache, so flushing a qcow2 image actually
      consists of writing back that cache to the protocol and only then flushes the
      protocol in order to get everything stable on disk.
      
      This introduces a separate bdrv_co_flush_to_os to reflect the split.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      eb489bb1
    • K
      block: Rename bdrv_co_flush to bdrv_co_flush_to_disk · c68b89ac
      Kevin Wolf 提交于
      There are two different types of flush that you can do: Flushing one level up
      to the OS (i.e. writing data to the host page cache) or flushing it all the way
      down to the disk. The existing functions flush to the disk, reflect this in the
      function name.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      c68b89ac