1. 10 12月, 2014 3 次提交
  2. 24 11月, 2014 1 次提交
  3. 20 10月, 2014 3 次提交
  4. 10 9月, 2014 2 次提交
  5. 15 8月, 2014 2 次提交
  6. 28 6月, 2014 2 次提交
  7. 30 5月, 2014 1 次提交
  8. 19 5月, 2014 1 次提交
    • P
      block: optimize zero writes with bdrv_write_zeroes · 465bee1d
      Peter Lieven 提交于
      this patch tries to optimize zero write requests
      by automatically using bdrv_write_zeroes if it is
      supported by the format.
      
      This significantly speeds up file system initialization and
      should speed zero write test used to test backend storage
      performance.
      
      I ran the following 2 tests on my internal SSD with a
      50G QCOW2 container and on an attached iSCSI storage.
      
      a) mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/vdX
      
      QCOW2         [off]     [on]     [unmap]
      -----
      runtime:       14secs    1.1secs  1.1secs
      filesize:      937M      18M      18M
      
      iSCSI         [off]     [on]     [unmap]
      ----
      runtime:       9.3s      0.9s     0.9s
      
      b) dd if=/dev/zero of=/dev/vdX bs=1M oflag=direct
      
      QCOW2         [off]     [on]     [unmap]
      -----
      runtime:       246secs   18secs   18secs
      filesize:      51G       192K     192K
      throughput:    203M/s    2.3G/s   2.3G/s
      
      iSCSI*        [off]     [on]     [unmap]
      ----
      runtime:       8mins     45secs   33secs
      throughput:    106M/s    1.2G/s   1.6G/s
      allocated:     100%      100%     0%
      
      * The storage was connected via an 1Gbit interface.
        It seems to internally handle writing zeroes
        via WRITESAME16 very fast.
      Signed-off-by: NPeter Lieven <pl@kamp.de>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      465bee1d
  9. 30 4月, 2014 1 次提交
  10. 18 2月, 2014 1 次提交
  11. 24 1月, 2014 2 次提交
  12. 29 11月, 2013 2 次提交
    • F
      qapi: Change BlockDirtyInfo to list · 21b56835
      Fam Zheng 提交于
      We have multiple dirty bitmaps in BDS now, switch QAPI to allow query
      it (BlockInfo.dirty_bitmaps), and also drop old BlockInfo.dirty.
      Signed-off-by: NFam Zheng <famz@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      21b56835
    • F
      block: per caller dirty bitmap · e4654d2d
      Fam Zheng 提交于
      Previously a BlockDriverState has only one dirty bitmap, so only one
      caller (e.g. a block job) can keep track of writing. This changes the
      dirty bitmap to a list and creates a BdrvDirtyBitmap for each caller, the
      lifecycle is managed with these new functions:
      
          bdrv_create_dirty_bitmap
          bdrv_release_dirty_bitmap
      
      Where BdrvDirtyBitmap is a linked list wrapper structure of HBitmap.
      
      In place of bdrv_set_dirty_tracking, a BdrvDirtyBitmap pointer argument
      is added to these functions, since each caller has its own dirty bitmap:
      
          bdrv_get_dirty
          bdrv_dirty_iter_init
          bdrv_get_dirty_count
      
      bdrv_set_dirty and bdrv_reset_dirty prototypes are unchanged but will
      internally walk the list of all dirty bitmaps and set them one by one.
      Signed-off-by: NFam Zheng <famz@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      e4654d2d
  13. 11 10月, 2013 2 次提交
  14. 06 9月, 2013 3 次提交
  15. 07 6月, 2013 3 次提交
  16. 04 6月, 2013 2 次提交