On 04/27/2010 01:36 AM, Anthony Liguori wrote:
A few comments:
1) The problem was not block watermark itself but generating a
notification on the watermark threshold. It's a heuristic and should
be implemented based on polling block stats.
Polling for an event that never happens is bad engineering. What
frequency do you poll? you're forcing the user to make a lose-lose
tradeoff.
Otherwise, we'll be adding tons of events to qemu that we'll struggle
to maintain.
That's not a valid reason to reject a user requirement. We may argue
the requirement is bogus, or that the suggested implementation is wrong
and point in a different direction, but saying that we may have to add
more code in the future due to other requirements is ... well I can't
find a word for it.
2) A block plugin doesn't solve the problem if it's just at the
BlockDriverState level because it can't interact with qcow2.
Why not? We have a layered model. guest -> qcow2 -> plugin (sends
event) -> raw-posix. Just need to insert the plugin at the appropriate
layer.
3) For general block plugins, it's probably better to tackle userspace
block devices. We have CUSE and FUSE already, a BUSE is a logical
conclusion.
We also have an nbd client.
Here's another option: an nbd-like protocol that remotes all
BlockDriver operations except read and write over a unix domain socket.
The open operation returns an fd (SCM_RIGHTS strikes again) that is used
for read and write. This can be used to implement snapshots over LVM,
for example.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
