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