[cc xfs] On Tue, Jul 25, 2017 at 06:20:54PM +0200, Luis R. Rodriguez wrote: > On Thu, Jun 15, 2017 at 03:00:02PM -0700, Darrick J. Wong wrote: > > Document the metadump file format. > > Thanks for all this! I have started wondering all this and was > curious if there are perhaps more docs about the format or more > practical docs which can help one go read the dumps and help > analyze through examples. > > > --- /dev/null > > +++ b/design/XFS_Filesystem_Structure/metadump.asciidoc > > +== Dump Obfuscation > > + > > +Unless explicitly disabled, the +xfs_metadump+ tool obfuscates empty block > > +space and naming information to avoid leaking sensitive information into > > +the metadump file. +xfs_metadump+ does not copy user data blocks. > > + > > +The obfuscation policy is as follows: > > + > > +* File and extended attribute names are both considered "names". > > +* Names longer than 8 characters are totally rewritten with a name that matches the hash of the old name. > > +* Names between 5 and 8 characters are partially rewritten to match the hash of the old name. > > Any reason for this? /me doesn't know. Maybe it's too hard to generate a new name with the same hash? > > +* Names shorter than 5 characters are not obscured at all. > > This does not seem like a good idea, do we have a record of why this was done > historically? > > > +* Names that cross a block boundary are not obscured at all. > > Likewise. iirc we basically copy things a block at a time, which makes it harder to deal with multi-fsblock dirblocks (???) I don't really know, let's see if the list remembers. :) --D > > Luis -- 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
