On 07/19/2017 04:08 PM, 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): > File names: > 10-stdio > 6-log-shell_2-stdio.bz2 > 8-log-shell_4-stdio > :(%40-log-MasterShellCommand_1-stdio.bz2 <snip way too many strings> > > I used the current git version like this: > ./db/xfs_db -f -i -p xfs_metadump -c "metadump -e -g -w -" > xfs-meta.rawimg | strings ok, that shoulda worked... I wonder how to debug this, if you can't legally share the problematic image with me to investigate... I put a lot of effort into selectively zeroing out unused portions of metablocks a couple years back, I am surprised that this much remains. I wonder if something regressed ... -Eric > commit e116c5c4511bbc2d98579817232258d57a1f1777 > Author: Eric Sandeen <sandeen@xxxxxxxxxx> > Date: Fri May 5 13:25:49 2017 -0500 -- 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
