Re: Collecting aged XFS profiles

[Dave Chinner <david@fromorbit.com>]

On Wed, Jul 19, 2017 at 10:55:23PM -0500, Eric Sandeen wrote:
> 
> 
> On 07/19/2017 10:02 PM, Dave Chinner wrote:
> > On Wed, Jul 19, 2017 at 11:08:41PM +0200, Stefan Ring wrote:
> >> On Wed, Jul 19, 2017 at 5:20 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> >>> On 07/19/2017 02:59 AM, Stefan Ring wrote:
> >>>> I have created a metadump that is 1GB in size, xz-compressed. However,
> >>>> by running strings on it I find that there are many identifiable
> >>>> remains inside, and I cannot legally pass this on.
> >>>
> >>> newer metadump should correct that problem, and is a read-only tool,
> >>> so should be (tm) perfectly safe (tm).  You could run it out of a built
> >>> git repo, via the xfs_db commands.
> >>>
> >>>> The question is: can I import this metadata image in a VM and recreate
> >>>> the metadata image from there, using modern xfsprogs? Will this
> >>>> preserve most of the relevant information?
> >>>
> >>> yes, that would work too. (mdrestore followed by or piped through metadump)
> >>> If you find significant strings in that result please let me know :)
> >>
> >> There is still quite a lot of stuff that should not be there (pasted
> >> selectively while scrolling over it via less):
> > 
> > [snip]
> > 
> > This stuff could all be in the journal. This is why I said "metadump
> > will first need to be modified to avoid dumping the journal".
> > Shouldn't be too hard - we already avoid dumping the journal when it
> > is external....
> 
> We already (in effect) avoid dumping it when it's clean:
> 
>         dirty = xlog_is_dirty(mp, &log, &x, 0);
> 
>         switch (dirty) {
>         case 0:
>                 /* clear out a clean log */
>                 if (show_progress)
>                         print_progress("Zeroing clean log");
> 		...
> 		libxfs_log_clear( ...
> 
> and if it /wasn't/ clean, he'd have gotten the warning:
> 
> _("Warning: log recovery of an obfuscated metadata image can leak "
> "unobfuscated metadata and/or cause image corruption.  If possible, "
> "please mount the filesystem to clean the log, or disable obfuscation."));

Oh, that's in the for-next branch, not the master branch. No wonder
I couldn't find this at first. :/

FWIW, people building from the git tree are probably using the
master branch (v4.11.0), not the for-next branch. I used to stage
all the -rcX releases in the master branch, which was why I was
confused by this at first. Never mind, I'll update my scripts that
haven't been pulling the xfsprogs for-next branch from kernel.org...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com