From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UV2CZ-0006bt-OA for qemu-devel@nongnu.org; Wed, 24 Apr 2013 12:05:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UV2CP-0007vp-VI for qemu-devel@nongnu.org; Wed, 24 Apr 2013 12:05:47 -0400 Received: from borage.mail.virginia.edu ([128.143.2.34]:52653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UV2CP-0007vi-QK for qemu-devel@nongnu.org; Wed, 24 Apr 2013 12:05:37 -0400 Received: from localhost (localhost [127.0.0.1]) by borage.mail.virginia.edu (Postfix) with ESMTP id 6760825A437 for ; Wed, 24 Apr 2013 12:05:37 -0400 (EDT) Received: from borage.mail.virginia.edu ([127.0.0.1]) by localhost (borage-f.mail.virginia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fv4eVIdVI+vF for ; Wed, 24 Apr 2013 12:05:37 -0400 (EDT) Received: from iron1.mail.virginia.edu (iron1-s.mail.virginia.edu [10.250.200.226]) by borage.mail.virginia.edu (Postfix) with ESMTP id 41DBC25A436 for ; Wed, 24 Apr 2013 12:05:37 -0400 (EDT) Received: by mail-ea0-f199.google.com with SMTP id h14so2596268eak.10 for ; Wed, 24 Apr 2013 09:05:36 -0700 (PDT) MIME-Version: 1.0 Sender: wor6c@virginia.edu In-Reply-To: <20130424083940.GC20971@stefanha-thinkpad.redhat.com> References: <20130424083940.GC20971@stefanha-thinkpad.redhat.com> Date: Wed, 24 Apr 2013 12:05:35 -0400 Message-ID: From: Wolfgang Richter Content-Type: multipart/alternative; boundary=001a11c26804ebbcfb04db1d78b4 Subject: Re: [Qemu-devel] Adding Disk-Level Introspection to QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel --001a11c26804ebbcfb04db1d78b4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 24, 2013 at 4:39 AM, Stefan Hajnoczi 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 > wrote: > > > > > On Tue, Apr 23, 2013 at 2:21 PM, Stefan Hajnoczi >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 --001a11c26804ebbcfb04db1d78b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 4:39 AM, Stefan Hajnoczi <stefan= ha@gmail.com> wrote:
On T= ue, Apr 23, 2013 at 03:11:26PM -0400, Wolfgang Richter wrote:
> On Tue, Apr 23, 2013 at 2:31 PM, Wolfgang Richter <wolf@cs.cmu.edu> wrote:
>
> > On Tue, Apr 23, 2013 at 2:21 PM, Stefan Hajnoczi <stefanha@gmail.com>wrote:
> >
> >> Eric's suggestion to use NBD makes sense to me. =A0The bl= ock-backup code
> >> can be extended fairly easier using sync mode=3Dnone (do not = perform a
> >> background copy of the entire disk) and by disabling the bitm= ap
> >> (essentially "tap" mode).
> >
> >
> Also, as another thought, I think I can actually use the bitmap to imp= lement
> an optimization. =A0In my code, I already use a bitmap to determine wh= ich
> sectors I want to introspect (ignoring portions of the disk greatly re= duces
> required bandwidth and overhead; swap space for example isn't gene= rally
> interesting unless you can interpret memory as well). =A0 So I think I= can
> adapt
> my code here as well.

Cool. =A0By the way, do you actually care about the data being = written or
just which sectors were touched?


Excellent question, my example wasn't clea= r. =A0I do want the data _especially_
for sectors=A0contain= ing file system metadata because I interpret metadata (for
NTFS and ext4 currently) to figure out new sectors associated wi= th a file or
file creations and file deletions.

But, if there is a system that is write-heavy, I&= #39;m OK with dropping data writes
to regular files (not file system metadata). =A0In that case, pe= ople interested in
say monitoring web server logs would los= e the data stream from their log files,
but the introspecti= on system as a whole maintains its view of the file system
space.=A0

--
Wolf
--001a11c26804ebbcfb04db1d78b4--