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@xxxxxxxxxxx> 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@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
