On Wed, Nov 08, 2023 at 02:02:28PM +0530, Chandan Babu R wrote:
> Metadump v2 is the new metadata dump format introduced in upstream
> xfsprogs. This commit describes V2 format's ondisk structure.
>
> Signed-off-by: Chandan Babu R <chandan.babu@xxxxxxxxxx>
This is consistent with the C structures in the metadump2 patchset, so
Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx>
(But I'll wait until cem merges that patchset before taking this.)
((Assuming I'm still xfs-docs maintainer :P))
(((Ok I declare I still am)))
--D
> ---
> .../metadump.asciidoc | 75 ++++++++++++++++++-
> 1 file changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/design/XFS_Filesystem_Structure/metadump.asciidoc b/design/XFS_Filesystem_Structure/metadump.asciidoc
> index 2f35b7e..7ce993c 100644
> --- a/design/XFS_Filesystem_Structure/metadump.asciidoc
> +++ b/design/XFS_Filesystem_Structure/metadump.asciidoc
> @@ -13,7 +13,11 @@ must be the superblock from AG 0. If the metadump has more blocks than
> can be pointed to by the +xfs_metablock.mb_daddr+ area, the sequence
> of +xfs_metablock+ followed by metadata blocks is repeated.
>
> -.Metadata Dump Format
> +Two metadump file formats are supported: +V1+ and +V2+. In addition to
> +the features supported by the +V1+ format, the +V2+ format supports
> +capturing data from an external log device.
> +
> +== Metadata Dump v1 Format
>
> [source, c]
> ----
> @@ -62,6 +66,75 @@ An array of disk addresses. Each of the +mb_count+ blocks (of size +(1
> << mb_blocklog+) following the +xfs_metablock+ should be written back to
> the address pointed to by the corresponding +mb_daddr+ entry.
>
> +== Metadata Dump v2 Format
> +
> +A Metadump Dump in the V2 format begins with a header represented by
> ++struct xfs_metadump_header+.
> +[source, c]
> +----
> +struct xfs_metadump_header {
> + __be32 xmh_magic;
> + __be32 xmh_version;
> + __be32 xmh_compat_flags;
> + __be32 xmh_incompat_flags;
> + __be64 xmh_reserved;
> +} __packed;
> +----
> +*xmh_magic*::
> +The magic number, ``XMD2'' (0x584D4432)
> +
> +*xmh_version*::
> +The version number, i.e. 2.
> +
> +*xmh_compat flags*::
> +Compat flags describing a metadata dump.
> +
> +[options="header"]
> +|=====
> +| Flag | Description
> +| +XFS_MD2_COMPAT_OBFUSCATED+ |
> +Directory entry and extended attribute names have been obscured and
> +extended attribute values are zeroed to protect privacy.
> +
> +| +XFS_MD2_COMPAT_FULLBLOCKS+ |
> +Full metadata blocks have been dumped. Without this flag, unused areas
> +of metadata blocks are zeroed.
> +
> +| +XFS_MD2_COMPAT_DIRTYLOG+ |
> +Log was dirty.
> +
> +| +XFS_MD2_COMPAT_EXTERNALLOG+ |
> +Metadata dump contains contents from an external log.
> +|=====
> +
> +*xmh_incompat_flags*::
> +Incompat flags describing a metadata dump. At present, this field must
> +be set to zero.
> +
> +*xmh_reserved*::
> +Reserved. Should be zero.
> +
> +The header is followed by an alternating sequence of +struct
> +xfs_meta_extent+ and the contents from the corresponding variable
> +length extent.
> +
> +[source, c]
> +----
> +struct xfs_meta_extent {
> + __be64 xme_addr;
> + __be32 xme_len;
> +} __packed;
> +----
> +*xme_addr*::
> +
> +The lower 54 bits are used to store the disk address of a metadata dump
> +extent. The next 2 bits are used for indicating the device.
> +. 00 - Data device
> +. 01 - External log
> +
> +*xme_len*::
> +Length of the metadata dump extent in units of 512 byte blocks.
> +
> == Dump Obfuscation
>
> Unless explicitly disabled, the +xfs_metadump+ tool obfuscates empty block
> --
> 2.39.1
>
