On 07/19/2017 11:38 PM, Dave Chinner wrote:
> 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. :/
Well the clean log handling has been there for a couple of years; the
warning is new, yes.
> 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...
yeah, I was doing that when I was new to the maintainer game, for-next
was rebasable and more forgiving. Maybe I should change that back.
-Eric
> Cheers,
>
> Dave.
>
--
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
