Re: [PATCH V1 2/2] metadump.asciidoc: Add description for metadump v2 ondisk format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 06, 2023 at 06:51:58PM +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>
> ---
>  .../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..782f194 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
> +dumping data from an external log device.

"...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;

   ^^^^^ spaces not tabs (yeah, I know...)

> +        __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 blocks have been dumped.

"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;

Inconsistent indenting here too.

> +} __packed;
> +----
> +*xme_addr*::
> +
> +
> +The lowest 54 bits are used to store 512 byte disk addresses of a
> +metadata extent . The next 2 bits are used for indicating the device.

                  ^ no space here.

"The lower 54 bits are used to store the disk address of a metadata dump
extent.  The next 2 bits..."

> +. 00 - Data device
> +. 01 - External log
> +
> +*xme_len*::
> +Length of the Metadata in units of 512 byte blocks.

"Length of the metadata dump extent in units of 512 byte blocks."

(Hey, uh, who's the xfs documentation maintainer?  Is it still me?)

--D

> +
>  == Dump Obfuscation
>  
>  Unless explicitly disabled, the +xfs_metadump+ tool obfuscates empty block
> -- 
> 2.39.1
> 



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux