1. 23 5月, 2018 2 次提交
  2. 15 5月, 2018 5 次提交
  3. 08 5月, 2018 2 次提交
    • M
      block/mirror: Make cancel always cancel pre-READY · eb36639f
      Max Reitz 提交于
      Commit b76e4458 made the mirror block
      job respect block-job-cancel's @force flag: With that flag set, it would
      now always really cancel, even post-READY.
      
      Unfortunately, it had a side effect: Without that flag set, it would now
      never cancel, not even before READY.  Considering that is an
      incompatible change and not noted anywhere in the commit or the
      description of block-job-cancel's @force parameter, this seems
      unintentional and we should revert to the previous behavior, which is to
      immediately cancel the job when block-job-cancel is called before source
      and target are in sync (i.e. before the READY event).
      
      Cc: qemu-stable@nongnu.org
      Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1572856Reported-by: NYanan Fu <yfu@redhat.com>
      Signed-off-by: NMax Reitz <mreitz@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-id: 20180501220509.14152-2-mreitz@redhat.com
      Reviewed-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      eb36639f
    • S
      block/mirror: honor ratelimit again · ddc4115e
      Stefan Hajnoczi 提交于
      Commit b76e4458 ("block/mirror: change
      the semantic of 'force' of block-job-cancel") accidentally removed the
      ratelimit in the mirror job.
      
      Reintroduce the ratelimit but keep the block-job-cancel force=true
      behavior that was added in commit
      b76e4458.
      
      Note that block_job_sleep_ns() returns immediately when the job is
      cancelled.  Therefore it's safe to unconditionally call
      block_job_sleep_ns() - a cancelled job does not sleep.
      
      This commit fixes the non-deterministic qemu-iotests 185 output.  The
      test relies on the ratelimit to make the job sleep until the 'quit'
      command is processed.  Previously the job could complete before the
      'quit' command was received since there was no ratelimit.
      
      Cc: Liang Li <liliang.opensource@gmail.com>
      Cc: Jeff Cody <jcody@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Message-id: 20180424123527.19168-1-stefanha@redhat.com
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      ddc4115e
  4. 19 3月, 2018 2 次提交
    • L
      block/mirror: change the semantic of 'force' of block-job-cancel · b76e4458
      Liang Li 提交于
      When doing drive mirror to a low speed shared storage, if there was heavy
      BLK IO write workload in VM after the 'ready' event, drive mirror block job
      can't be canceled immediately, it would keep running until the heavy BLK IO
      workload stopped in the VM.
      
      Libvirt depends on the current block-job-cancel semantics, which is that
      when used without a flag after the 'ready' event, the command blocks
      until data is in sync.  However, these semantics are awkward in other
      situations, for example, people may use drive mirror for realtime
      backups while still wanting to use block live migration.  Libvirt cannot
      start a block live migration while another drive mirror is in progress,
      but the user would rather abandon the backup attempt as broken and
      proceed with the live migration than be stuck waiting for the current
      drive mirror backup to finish.
      
      The drive-mirror command already includes a 'force' flag, which libvirt
      does not use, although it documented the flag as only being useful to
      quit a job which is paused.  However, since quitting a paused job has
      the same effect as abandoning a backup in a non-paused job (namely, the
      destination file is not in sync, and the command completes immediately),
      we can just improve the documentation to make the force flag obviously
      useful.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Jeff Cody <jcody@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: Max Reitz <mreitz@redhat.com>
      Cc: Eric Blake <eblake@redhat.com>
      Cc: John Snow <jsnow@redhat.com>
      Reported-by: NHuaitong Han <huanhuaitong@didichuxing.com>
      Signed-off-by: NHuaitong Han <huanhuaitong@didichuxing.com>
      Signed-off-by: NLiang Li <liliangleo@didichuxing.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      b76e4458
    • J
      blockjobs: model single jobs as transactions · 75859b94
      John Snow 提交于
      model all independent jobs as single job transactions.
      
      It's one less case we have to worry about when we add more states to the
      transition machine. This way, we can just treat all job lifetimes exactly
      the same. This helps tighten assertions of the STM graph and removes some
      conditionals that would have been needed in the coming commits adding a
      more explicit job lifetime management API.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      75859b94
  5. 03 3月, 2018 1 次提交
  6. 29 11月, 2017 1 次提交
  7. 26 10月, 2017 3 次提交
    • E
      block: Convert bdrv_get_block_status_above() to bytes · 31826642
      Eric Blake 提交于
      We are gradually moving away from sector-based interfaces, towards
      byte-based.  In the common case, allocation is unlikely to ever use
      values that are not naturally sector-aligned, but it is possible
      that byte-based values will let us be more precise about allocation
      at the end of an unaligned file that can do byte-based access.
      
      Changing the name of the function from bdrv_get_block_status_above()
      to bdrv_block_status_above() ensures that the compiler enforces that
      all callers are updated.  Likewise, since it a byte interface allows
      an offset mapping that might not be sector aligned, split the mapping
      out of the return value and into a pass-by-reference parameter.  For
      now, the io.c layer still assert()s that all uses are sector-aligned,
      but that can be relaxed when a later patch implements byte-based
      block status in the drivers.
      
      For the most part this patch is just the addition of scaling at the
      callers followed by inverse scaling at bdrv_block_status(), plus
      updates for the new split return interface.  But some code,
      particularly bdrv_block_status(), gets a lot simpler because it no
      longer has to mess with sectors.  Likewise, mirror code no longer
      computes s->granularity >> BDRV_SECTOR_BITS, and can therefore drop
      an assertion about alignment because the loop no longer depends on
      alignment (never mind that we don't really have a driver that
      reports sub-sector alignments, so it's not really possible to test
      the effect of sub-sector mirroring).  Fix a neighboring assertion to
      use is_power_of_2 while there.
      
      For ease of review, bdrv_get_block_status() was tackled separately.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      31826642
    • E
      block: Make bdrv_round_to_clusters() signature more useful · 7cfd5275
      Eric Blake 提交于
      In the process of converting sector-based interfaces to bytes,
      I'm finding it easier to represent a byte count as a 64-bit
      integer at the block layer (even if we are internally capped
      by SIZE_MAX or even INT_MAX for individual transactions, it's
      still nicer to not have to worry about truncation/overflow
      issues on as many variables).  Update the signature of
      bdrv_round_to_clusters() to uniformly use int64_t, matching
      the signature already chosen for bdrv_is_allocated and the
      fact that off_t is also a signed type, then adjust clients
      according to the required fallout (even where the result could
      now exceed 32 bits, no client is directly assigning the result
      into a 32-bit value without breaking things into a loop first).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      7cfd5275
    • E
      block: Allow NULL file for bdrv_get_block_status() · 298a1665
      Eric Blake 提交于
      Not all callers care about which BDS owns the mapping for a given
      range of the file.  This patch merely simplifies the callers by
      consolidating the logic in the common call point, while guaranteeing
      a non-NULL file to all the driver callbacks, for no semantic change.
      The only caller that does not care about pnum is bdrv_is_allocated,
      as invoked by vvfat; we can likewise add assertions that the rest
      of the stack does not have to worry about a NULL pnum.
      
      Furthermore, this will also set the stage for a future cleanup: when
      a caller does not care about which BDS owns an offset, it would be
      nice to allow the driver to optimize things to not have to return
      BDRV_BLOCK_OFFSET_VALID in the first place.  In the case of fragmented
      allocation (for example, it's fairly easy to create a qcow2 image
      where consecutive guest addresses are not at consecutive host
      addresses), the current contract requires bdrv_get_block_status()
      to clamp *pnum to the limit where host addresses are no longer
      consecutive, but allowing a NULL file means that *pnum could be
      set to the full length of known-allocated data.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      298a1665
  8. 06 10月, 2017 8 次提交
  9. 26 9月, 2017 1 次提交
  10. 05 9月, 2017 1 次提交
  11. 23 8月, 2017 1 次提交
  12. 24 7月, 2017 1 次提交
    • K
      block: Skip implicit nodes in query-block/blockstats · d3c8c674
      Kevin Wolf 提交于
      Commits 0db832f4 and 6cdbceb1 introduced the automatic insertion of filter
      nodes above the top layer of mirror and commit block jobs. The
      assumption made there was that since libvirt doesn't do node-level
      management of the block layer yet, it shouldn't be affected by added
      nodes.
      
      This is true as far as commands issued by libvirt are concerned. It only
      uses BlockBackend names to address nodes, so any operations it performs
      still operate on the root of the tree as intended.
      
      However, the assumption breaks down when you consider query commands,
      which return data for the wrong node now. These commands also return
      information on some child nodes (bs->file and/or bs->backing), which
      libvirt does make use of, and which refer to the wrong nodes, too.
      
      One of the consequences is that oVirt gets wrong information about the
      image size and stops the VM in response as long as a mirror or commit
      job is running:
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1470634
      
      This patch fixes the problem by hiding the implicit nodes created
      automatically by the mirror and commit block jobs in the output of
      query-block and BlockBackend-based query-blockstats as long as the user
      doesn't indicate that they are aware of those nodes by providing a node
      name for them in the QMP command to start the block job.
      
      The node-based commands query-named-block-nodes and query-blockstats
      with query-nodes=true still show all nodes, including implicit ones.
      This ensures that users that are capable of node-level management can
      still access the full information; users that only know BlockBackends
      won't use these commands.
      
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Tested-by: NEric Blake <eblake@redhat.com>
      d3c8c674
  13. 11 7月, 2017 1 次提交
  14. 10 7月, 2017 10 次提交
  15. 26 6月, 2017 1 次提交