On Wed, Apr 24, 2013 at 5:26 AM, Paolo Bonzini <pbonz...@redhat.com> wrote:
> Il 23/04/2013 20:31, Wolfgang Richter ha scritto: > > On Tue, Apr 23, 2013 at 2:21 PM, Stefan Hajnoczi <stefa...@gmail.com > > <mailto:stefa...@gmail.com>> wrote: > > > > 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. > > If you are okay with writes being "bundled" and you are able to handle > 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
