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
