1. 28 4月, 2017 2 次提交
  2. 24 4月, 2017 1 次提交
  3. 17 3月, 2017 1 次提交
  4. 07 3月, 2017 2 次提交
  5. 01 3月, 2017 11 次提交
  6. 21 2月, 2017 1 次提交
  7. 16 1月, 2017 1 次提交
    • P
      block: get rid of bdrv_io_unplugged_begin/end · 8f90b5e9
      Paolo Bonzini 提交于
      bdrv_io_plug and bdrv_io_unplug are only called (via their
      BlockBackend equivalents) after starting asynchronous I/O.
      bdrv_drain is not going to be called while they are running,
      because---even if a coroutine runs for some reason---it will
      only drain in the next iteration of the event loop through
      bdrv_co_yield_to_drain.
      
      So this mechanism is unnecessary, get rid of it.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Message-id: 20161129113334.605-1-pbonzini@redhat.com
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      8f90b5e9
  8. 09 1月, 2017 1 次提交
  9. 15 11月, 2016 1 次提交
    • J
      blockjob: refactor backup_start as backup_job_create · 111049a4
      John Snow 提交于
      Refactor backup_start as backup_job_create, which only creates the job,
      but does not automatically start it. The old interface, 'backup_start',
      is not kept in favor of limiting the number of nearly-identical interfaces
      that would have to be edited to keep up with QAPI changes in the future.
      
      Callers that wish to synchronously start the backup_block_job can
      instead just call block_job_start immediately after calling
      backup_job_create.
      
      Transactions are updated to use the new interface, calling block_job_start
      only during the .commit phase, which helps prevent race conditions where
      jobs may finish before we even finish building the transaction. This may
      happen, for instance, during empty block backup jobs.
      Reported-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1478587839-9834-6-git-send-email-jsnow@redhat.com
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      111049a4
  10. 01 11月, 2016 2 次提交
  11. 28 10月, 2016 3 次提交
  12. 28 9月, 2016 1 次提交
  13. 15 9月, 2016 1 次提交
  14. 13 9月, 2016 1 次提交
  15. 06 9月, 2016 3 次提交
  16. 18 8月, 2016 1 次提交
    • E
      block: fix deadlock in bdrv_co_flush · ce83ee57
      Evgeny Yakovlev 提交于
      The following commit
          commit 3ff2f67a
          Author: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
          Date:   Mon Jul 18 22:39:52 2016 +0300
          block: ignore flush requests when storage is clean
      has introduced a regression.
      
      There is a problem that it is still possible for 2 requests to execute
      in non sequential fashion and sometimes this results in a deadlock
      when bdrv_drain_one/all are called for BDS with such stalled requests.
      
      1. Current flushed_gen and flush_started_gen is 1.
      2. Request 1 enters bdrv_co_flush to with write_gen 1 (i.e. the same
         as flushed_gen). It gets past flushed_gen != flush_started_gen and
         sets flush_started_gen to 1 (again, the same it was before).
      3. Request 1 yields somewhere before exiting bdrv_co_flush
      4. Request 2 enters bdrv_co_flush with write_gen 2. It gets past
         flushed_gen != flush_started_gen and sets flush_started_gen to 2.
      5. Request 2 runs to completion and sets flushed_gen to 2
      6. Request 1 is resumed, runs to completion and sets flushed_gen to 1.
         However flush_started_gen is now 2.
      
      From here on out flushed_gen is always != to flush_started_gen and all
      further requests will wait on flush_queue. This change replaces
      flush_started_gen with an explicitly tracked active flush request.
      Signed-off-by: NEvgeny Yakovlev <eyakovlev@virtuozzo.com>
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Message-id: 1471457214-3994-2-git-send-email-den@openvz.org
      CC: Stefan Hajnoczi <stefanha@redhat.com>
      CC: Fam Zheng <famz@redhat.com>
      CC: Kevin Wolf <kwolf@redhat.com>
      CC: Max Reitz <mreitz@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      ce83ee57
  17. 04 8月, 2016 1 次提交
    • E
      block: Cater to iscsi with non-power-of-2 discard · b8d0a980
      Eric Blake 提交于
      Dell Equallogic iSCSI SANs have a very unusual advertised geometry:
      
      $ iscsi-inq -e 1 -c $((0xb0)) iscsi://XXX/0
      wsnz:0
      maximum compare and write length:1
      optimal transfer length granularity:0
      maximum transfer length:0
      optimal transfer length:0
      maximum prefetch xdread xdwrite transfer length:0
      maximum unmap lba count:30720
      maximum unmap block descriptor count:2
      optimal unmap granularity:30720
      ugavalid:1
      unmap granularity alignment:0
      maximum write same length:30720
      
      which says that both the maximum and the optimal discard size
      is 15M.  It is not immediately apparent if the device allows
      discard requests not aligned to the optimal size, nor if it
      allows discards at a finer granularity than the optimal size.
      
      I tried to find details in the SCSI Commands Reference Manual
      Rev. A on what valid values of maximum and optimal sizes are
      permitted, but while that document mentions a "Block Limits
      VPD Page", I couldn't actually find documentation of that page
      or what values it would have, or if a SCSI device has an
      advertisement of its minimal unmap granularity.  So it is not
      obvious to me whether the Dell Equallogic device is compliance
      with the SCSI specification.
      
      Fortunately, it is easy enough to support non-power-of-2 sizing,
      even if it means we are less efficient than truly possible when
      targetting that device (for example, it means that we refuse to
      unmap anything that is not a multiple of 15M and aligned to a
      15M boundary, even if the device truly does support a smaller
      granularity where unmapping actually works).
      Reported-by: NPeter Lieven <pl@kamp.de>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1469129688-22848-5-git-send-email-eblake@redhat.com>
      Acked-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b8d0a980
  18. 20 7月, 2016 4 次提交
  19. 19 7月, 2016 1 次提交
    • E
      block: ignore flush requests when storage is clean · 3ff2f67a
      Evgeny Yakovlev 提交于
      Some guests (win2008 server for example) do a lot of unnecessary
      flushing when underlying media has not changed. This adds additional
      overhead on host when calling fsync/fdatasync.
      
      This change introduces a write generation scheme in BlockDriverState.
      Current write generation is checked against last flushed generation to
      avoid unnessesary flushes.
      
      The problem with excessive flushing was found by a performance test
      which does parallel directory tree creation (from 2 processes).
      Results improved from 0.424 loops/sec to 0.432 loops/sec.
      Each loop creates 10^3 directories with 10 files in each.
      
      This affected some blkdebug testcases that were expecting error logs from
      failure-injected flushes which are now skipped entirely
      (tests 026 071 089).
      
      This also affects the performance of block jobs and thus BLOCK_JOB_READY
      events for driver-mirror and active block-commit commands now arrives
      faster, before QMP send successfully returns to caller (tests 141 144).
      Signed-off-by: NEvgeny Yakovlev <eyakovlev@virtuozzo.com>
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Message-id: 1468870792-7411-5-git-send-email-den@openvz.org
      CC: Kevin Wolf <kwolf@redhat.com>
      CC: Max Reitz <mreitz@redhat.com>
      CC: Stefan Hajnoczi <stefanha@redhat.com>
      CC: Fam Zheng <famz@redhat.com>
      CC: John Snow <jsnow@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      3ff2f67a
  20. 13 7月, 2016 1 次提交