Re: [PATCH] xfs_metadump: tag metadump image with attribute flags

[Dave Chinner <david@fromorbit.com>]

On Tue, May 23, 2017 at 10:47:50AM -0500, Eric Sandeen wrote:
> On 5/23/17 10:46 AM, Darrick J. Wong wrote:
> > On Mon, May 22, 2017 at 07:33:35PM -0500, Eric Sandeen wrote:
> >> After the long discussion about warning the user and/or consumer
> >> of xfs_metadumps about dirty logs, it crossed my mind that we
> >> could use the reserved slot in the metadump header to tag the
> >> file with attributes, so the consumer of the metadump knows how
> >> it was created.
> >>
> >> This patch adds 3 flags to describe the metadump: dirty log,
> >> obfuscated, and full blocks (unused portions of metadata blocks
> >> are not zeroed out).
> >>
> >> It then adds a new option to xfs_mdrestore, "-i" to show info,
> >> which can be used with or without a target file:
> 
> 
> >> +/* mb_flags */
> >> +#define XFS_METADUMP_OBFUSCATED	(1 << 0)
> >> +#define XFS_METADUMP_FULLBLOCKS	(1 << 1)
> >> +#define XFS_METADUMP_DIRTYLOG	(1 << 2)
> > 
> > If we always wrote zero for mb_reserved previously, how do we
> > distinguish between a non-obfuscated partial-block clean-log metadump
> > and an old metadump?  Do we care?
> 
> Oh right.  ;)
> 
> > I imagine metadumps are fairly transitory in nature, so it might not be
> > a big deal, and probably not worth burning 1/8 of our flag-space over
> > since AFAICT we don't use the(se) flags for any serious behavioral
> > changes.
> 
> OTOH, how many flags would we possibly have?  I'm ok with adding a
> "we have flags" flag, too.

We can't extend the metadump header in a backwards compatible way
unless mdrestore already rejects metadumps with non-zero mb_reserved
fields....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com