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@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
