On Wed, Apr 24, 2013 at 5:26 AM, Paolo Bonzini <address@hidden> wrote:
Il 23/04/2013 20:31, Wolfgang Richter ha scritto:> On Tue, Apr 23, 2013 at 2:21 PM, Stefan Hajnoczi <address@hidden> <mailto:address@hidden>> wrote:If you are okay with writes being "bundled" and you are able to handle
>
> The tracing subsystem is geared towards tracepoint instrumentation
> rather than binary dumps.
>
> Can you share some specific applications?
>
>
> Well, my main application is in exposing a "cloud-inotify" service by
> interpreting
> sector writes in real-time and publishing the updates as file system
> manipulations.
> By using introspection we don't need agents running inside the guest.
>
> Example: guest writes to sector 5786907; I reverse-map that sector and
> notice
> it belongs to '/etc/passwd' within that guest; I immediately emit a message
> (currently using Redis pub-sub functionality) to any interested
> subscribers that
> '/etc/passwd' changed within this guest running on a certain host within the
> datacenter.
reordered writes within a small timeframe (usually 0.1-1s), then you can
use drive-mirror with an NBD destination.
In the purest form, not to miss "updates" I'm not OK with it. But, I think
that introspection can still _mostly_ work given these relaxed constraints.
Reordered writes can be difficult to stomach though: imagine that a file inode
update goes through before its data writes. Imagine that the inode update
simply extends the file size, with the last data block write coming soon after.
We might incorrectly report bytes (and their contents) as belonging to this
file before we see the final data block write if the data block is currently
cached.
Wolf