Am 15.10.2014 um 09:55 hat Juan Quintela geschrieben:
> Hi
> 
> by popular demand, and after too many time, this series.  This is an
> RFC to know what people think about how to use them, the interface
> proposed, whatever.
> [...]
> 
> Kevin: You asked for optional sections in the past for the block
>    layer, would this proposal be enough for you?

I know I've asked in more than one occasion, and of course I don't
remember all the details any more. Anyway, I remember two cases offhand:

* qcow2 with patches like Delayed COW keeps internal block layer state
  in memory that might need to be migrated. This series looks fine for
  this case in principle, we'd just need to find a way to distinguish
  the affected BlockDriverStates. We can probably take a node-name if it
  exists (with Jeff's auto-naming patches not a problem, because then it
  would always exist)

  How do devices solve this? Do they use something like a qdev path to
  identify to which device a given section belongs?

* When a VM is stopped after an I/O error, we need to migrate the
  information about pending requests (bdrv_drain_all doesn't complete
  the failed requests). Currently we do this in device code, but it
  would be very nice to make this common block layer functionality.

  The problem here is that bdrv_aio_readv/writev get an opaque pointer
  back to the device, which of course becomes meaningless during
  migration.

  So this one is tricky even if we have optional top-level sections.

Kevin

Reply via email to