On Wed, Apr 24, 2013 at 4:39 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote:

> On Tue, Apr 23, 2013 at 03:11:26PM -0400, Wolfgang Richter wrote:
> > On Tue, Apr 23, 2013 at 2:31 PM, Wolfgang Richter <w...@cs.cmu.edu>
> wrote:
> >
> > > On Tue, Apr 23, 2013 at 2:21 PM, Stefan Hajnoczi <stefa...@gmail.com
> >wrote:
> > >
> > >> Eric's suggestion to use NBD makes sense to me.  The block-backup code
> > >> can be extended fairly easier using sync mode=none (do not perform a
> > >> background copy of the entire disk) and by disabling the bitmap
> > >> (essentially "tap" mode).
> > >
> > >
> > Also, as another thought, I think I can actually use the bitmap to
> implement
> > an optimization.  In my code, I already use a bitmap to determine which
> > sectors I want to introspect (ignoring portions of the disk greatly
> reduces
> > required bandwidth and overhead; swap space for example isn't generally
> > interesting unless you can interpret memory as well).   So I think I can
> > adapt
> > my code here as well.
>
> Cool.  By the way, do you actually care about the data being written or
> just which sectors were touched?
>
>
Excellent question, my example wasn't clear.  I do want the data
_especially_
for sectors containing file system metadata because I interpret metadata
(for
NTFS and ext4 currently) to figure out new sectors associated with a file or
file creations and file deletions.

But, if there is a system that is write-heavy, I'm OK with dropping data
writes
to regular files (not file system metadata).  In that case, people
interested in
say monitoring web server logs would lose the data stream from their log
files,
but the introspection system as a whole maintains its view of the file
system
space.

-- 
Wolf

Reply via email to