On 04/27/2010 04:03 PM, Anthony Liguori wrote:
On 04/27/2010 03:14 AM, Avi Kivity wrote:
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.
Polling is the best solution because it offers the most flexibility.
Baking the heuristic into qemu just removes flexibility for all
consumers.
Can you explain? The ability to poll is not removed. Nor is any
heuristics performed by qemu; it just sends a notification when a write
exceeds a user-defined threshold. The distance from the threshold to
the top-of-file is not known to qemu.
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.
All of the qcow2 information is static to the qcow2 driver and I don't
think changing that for plugins is a good idea.
There is no information that the plugin needs to access:
if (write_offset > watermark && watermark_enabled) {
send_notification();
watermark_enabled = false;
}
bdrv_write(backing_blockstate, ..., write_offset, ...);
Note write_offset if not the guest's offset, but the offset into the
backing file. It will trigger on guest writes and qcow2 metadata writes
alike.
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.
How does it address the watermark problem?
It doesn't. Mea confusa.
--
error compiling committee.c: too many arguments to function
--
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
