From patchwork Wed Nov 6 19:18:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13865339 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2936420BB28 for ; Wed, 6 Nov 2024 19:18:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730920735; cv=none; b=SqoGJEkIxFpTz0/eYncWnC/7ILLqTgYRoYPYYEsNfbkWjKa9Z+cbSBrAEadKkbObyCxoD4Uq2OjMo4N/KY4QqNfTsuBiX6GpanHFYM3nK9s7h3u3fvPN9P6gw5gBGoY0eb4gvWq2BijMX0Ke7SoIeX31hZowqWuoIINcoKgTeCI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730920735; c=relaxed/simple; bh=GI3FqCoYL7I94EIiQlSQ0syfkomGo3A60TH+sCeygk8=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=H8UE8ukQKk6zumWvyAp6xnJmwCsAcY8MrLD1vIX8bOXkwjMsRFgT2fxfx0YaWNkrmxLYTA4WSPTFfe6VKE3TjoMc8wHT9sKPoCJGLfTdd0ZJaE3Ba/by8AKXS/VaK6UOz3uFGlXKbzixw6MTFxGaVJstp5FAdr3l/wW1qrN8itQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IBPgzYjL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IBPgzYjL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A018DC4CEC6; Wed, 6 Nov 2024 19:18:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730920734; bh=GI3FqCoYL7I94EIiQlSQ0syfkomGo3A60TH+sCeygk8=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=IBPgzYjL81ZCfQjQ7ro1ua9lPjzTX3YiGchI60I2i0WaIXS4zr2qXKNA7ZDHEa6VE Nf6KHcyW9VMTUe6Xxus2dY87xBhvOlU4mTcOmJQxCDjH0C9MaJQPjoXnUbkaM3iR2H izV8d27Q6c/Y5hAYlxH/jr+dHsJy9P8i2RDmRSuCW94NwH/ZY+a5SexOhZh+7Cw8a2 oov3IWGzHjCVmRvQX/bRVkxV3MLLATc+VjBumE+5QkMigCyDAx/PJ79eT5iXa5OMLP XQZLYLtg9/DcoT3963yPHuDj4ohZY78L/hnuxFZBBtkj2jY0WE1FZxKp5gnjdCHJy7 wU/oi9LwZM1Ww== Date: Wed, 06 Nov 2024 11:18:54 -0800 Subject: [PATCH 1/4] design: move discussion of realtime volumes to a separate section From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <173092059714.2883258.9567907120205476743.stgit@frogsfrogsfrogs> In-Reply-To: <173092059696.2883258.7093773656482973762.stgit@frogsfrogsfrogs> References: <173092059696.2883258.7093773656482973762.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong In preparation for documenting the realtime modernization project, move the discussions of the realtime-realted ondisk metadata to a separate file. Since realtime reverse mapping btrees haven't been added to the filesystem yet, stop including them in the final output. Signed-off-by: Darrick J. Wong --- .../allocation_groups.asciidoc | 20 -------- .../internal_inodes.asciidoc | 36 +------------- design/XFS_Filesystem_Structure/realtime.asciidoc | 50 ++++++++++++++++++++ .../xfs_filesystem_structure.asciidoc | 2 + 4 files changed, 54 insertions(+), 54 deletions(-) create mode 100644 design/XFS_Filesystem_Structure/realtime.asciidoc diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc index ec59519dc2ffc1..5d560073d146ff 100644 --- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc +++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc @@ -1322,23 +1322,3 @@ core.magic = 0x494e The chunk record also indicates that this chunk has 32 inodes, and that the missing inodes are also ``free''. - -[[Real-time_Devices]] -== Real-time Devices - -The performance of the standard XFS allocator varies depending on the internal -state of the various metadata indices enabled on the filesystem. For -applications which need to minimize the jitter of allocation latency, XFS -supports the notion of a ``real-time device''. This is a special device -separate from the regular filesystem where extent allocations are tracked with -a bitmap and free space is indexed with a two-dimensional array. If an inode -is flagged with +XFS_DIFLAG_REALTIME+, its data will live on the real time -device. The metadata for real time devices is discussed in the section about -xref:Real-time_Inodes[real time inodes]. - -By placing the real time device (and the journal) on separate high-performance -storage devices, it is possible to reduce most of the unpredictability in I/O -response times that come from metadata operations. - -None of the XFS per-AG B+trees are involved with real time files. It is not -possible for real time files to share data blocks. diff --git a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc index eaa0a50aa848f3..68c86d30ff8206 100644 --- a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc +++ b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc @@ -287,41 +287,9 @@ Log sequence number of the last DQ block write. *dd_crc*:: Checksum of the DQ block. - [[Real-time_Inodes]] == Real-time Inodes There are two inodes allocated to managing the real-time device's space, the -Bitmap Inode and the Summary Inode. - -[[Real-Time_Bitmap_Inode]] -=== Real-Time Bitmap Inode - -The real time bitmap inode, +sb_rbmino+, tracks the used/free space in the -real-time device using an old-style bitmap. One bit is allocated per real-time -extent. The size of an extent is specified by the superblock's +sb_rextsize+ -value. - -The number of blocks used by the bitmap inode is equal to the number of -real-time extents (+sb_rextents+) divided by the block size (+sb_blocksize+) -and bits per byte. This value is stored in +sb_rbmblocks+. The nblocks and -extent array for the inode should match this. Each real time block gets its -own bit in the bitmap. - -[[Real-Time_Summary_Inode]] -=== Real-Time Summary Inode - -The real time summary inode, +sb_rsumino+, tracks the used and free space -accounting information for the real-time device. This file indexes the -approximate location of each free extent on the real-time device first by -log2(extent size) and then by the real-time bitmap block number. The size of -the summary inode file is equal to +sb_rbmblocks+ × log2(realtime device size) -× sizeof(+xfs_suminfo_t+). The entry for a given log2(extent size) and -rtbitmap block number is 0 if there is no free extents of that size at that -rtbitmap location, and positive if there are any. - -This data structure is not particularly space efficient, however it is a very -fast way to provide the same data as the two free space B+trees for regular -files since the space is preallocated and metadata maintenance is minimal. - -include::rtrmapbt.asciidoc[] +xref:Real-Time_Bitmap_Inode[Bitmap Inode] and the +xref:Real-Time_Summary_Inode[Summary Inode]. diff --git a/design/XFS_Filesystem_Structure/realtime.asciidoc b/design/XFS_Filesystem_Structure/realtime.asciidoc new file mode 100644 index 00000000000000..11426e8fdb632d --- /dev/null +++ b/design/XFS_Filesystem_Structure/realtime.asciidoc @@ -0,0 +1,50 @@ +[[Real-time_Devices]] += Real-time Devices + +The performance of the standard XFS allocator varies depending on the internal +state of the various metadata indices enabled on the filesystem. For +applications which need to minimize the jitter of allocation latency, XFS +supports the notion of a ``real-time device''. This is a special device +separate from the regular filesystem where extent allocations are tracked with +a bitmap and free space is indexed with a two-dimensional array. If an inode +is flagged with +XFS_DIFLAG_REALTIME+, its data will live on the real time +device. + +By placing the real time device (and the journal) on separate high-performance +storage devices, it is possible to reduce most of the unpredictability in I/O +response times that come from metadata operations. + +None of the XFS per-AG B+trees are involved with real time files. It is not +possible for real time files to share data blocks. + +[[Real-Time_Bitmap_Inode]] +== Free Space Bitmap Inode + +The real time bitmap inode, +sb_rbmino+, tracks the used/free space in the +real-time device using an old-style bitmap. One bit is allocated per real-time +extent. The size of an extent is specified by the superblock's +sb_rextsize+ +value. + +The number of blocks used by the bitmap inode is equal to the number of +real-time extents (+sb_rextents+) divided by the block size (+sb_blocksize+) +and bits per byte. This value is stored in +sb_rbmblocks+. The nblocks and +extent array for the inode should match this. Each real time block gets its +own bit in the bitmap. + +[[Real-Time_Summary_Inode]] +== Free Space Summary Inode + +The real time summary inode, +sb_rsumino+, tracks the used and free space +accounting information for the real-time device. This file indexes the +approximate location of each free extent on the real-time device first by +log2(extent size) and then by the real-time bitmap block number. The size of +the summary inode file is equal to +sb_rbmblocks+ × log2(realtime device size) +× sizeof(+xfs_suminfo_t+). The entry for a given log2(extent size) and +rtbitmap block number is 0 if there is no free extents of that size at that +rtbitmap location, and positive if there are any. + +This data structure is not particularly space efficient, however it is a very +fast way to provide the same data as the two free space B+trees for regular +files since the space is preallocated and metadata maintenance is minimal. + +include::rtrmapbt.asciidoc[] diff --git a/design/XFS_Filesystem_Structure/xfs_filesystem_structure.asciidoc b/design/XFS_Filesystem_Structure/xfs_filesystem_structure.asciidoc index 689e2a874c13e9..a643d18add6094 100644 --- a/design/XFS_Filesystem_Structure/xfs_filesystem_structure.asciidoc +++ b/design/XFS_Filesystem_Structure/xfs_filesystem_structure.asciidoc @@ -84,6 +84,8 @@ include::journaling_log.asciidoc[] include::internal_inodes.asciidoc[] +include::realtime.asciidoc[] + include::fs_properties.asciidoc[] :leveloffset: 0 From patchwork Wed Nov 6 19:19:09 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13865340 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B97320BB2D for ; Wed, 6 Nov 2024 19:19:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730920751; cv=none; b=Aj2J0wHhdL20QJyYnfmHMPzJjLqRoxKB6STKXyw5D4MgMJmPoxM129k9dEhQMX8LbZN9DMcLO00K5qFFkVC26LTDtDXH29jTL64jcMH/zhGv2zhEqo1XKw7T9LGlpVoMuw73SCFGCNZUqFG6rM4JUEqXLpE6zQq5/FbjWjKnCks= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730920751; c=relaxed/simple; bh=0TEuBroQb0AYJtk98GiasfrVtsc/5apa9k7zzEoXx8Q=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=UeCBnUIhgWeDHZfb9z9Lxy5zTqpviZ8NwRKJJqaP88ehaPdBw4d0AHMQd0brHI/Gli2pHYYPKV5Q4Yr69sROL44cf2MHzHhfiQlQD35yNDwZyq0Z+Odh8Ws0FH87tymJnQm/LRFeW5/mL3wMNbjJYnfU8MByaiA66yDvIW7nms4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m0DdyhBa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m0DdyhBa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8827BC4CEC6; Wed, 6 Nov 2024 19:19:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730920750; bh=0TEuBroQb0AYJtk98GiasfrVtsc/5apa9k7zzEoXx8Q=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=m0DdyhBal62t8jXnwPdXFniKTgDf7Fa2/mJJjDtVVjScikQaEYZhp/VlwJO2nQW90 nV3BErCgBRjuzGsPcZjTFRqDAWvIZ9lelCpFow0vmey0H4Yfsht4QRJ5ol8XYXnJ/n yTjivMGM4GCDyMAo0MRPlLKzwLOVbqraDOYV389SoeUPjIjMqz7s69M/ARkj6/+iou Mc5V2j+Xd/sHbZWZQJNsU+SbfxRa0AfMpc+wdKwnWa09sK/DcZt+PvYPEpaRMo1452 VoxoeiQQdOJ1Mej07Ct5Iqjn8nzYEfSDsEUwpWrWalJ++HbutNqR2tlLpUUPSGLCWZ H2R5FYvcn8Hkw== Date: Wed, 06 Nov 2024 11:19:09 -0800 Subject: [PATCH 2/4] design: document realtime groups From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <173092059729.2883258.3327326591290447581.stgit@frogsfrogsfrogs> In-Reply-To: <173092059696.2883258.7093773656482973762.stgit@frogsfrogsfrogs> References: <173092059696.2883258.7093773656482973762.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Document the ondisk changes for realtime allocation groups. Signed-off-by: Darrick J. Wong --- .../allocation_groups.asciidoc | 31 ++ .../XFS_Filesystem_Structure/common_types.asciidoc | 4 .../internal_inodes.asciidoc | 2 design/XFS_Filesystem_Structure/magic.asciidoc | 3 .../XFS_Filesystem_Structure/ondisk_inode.asciidoc | 2 design/XFS_Filesystem_Structure/realtime.asciidoc | 344 ++++++++++++++++++++ 6 files changed, 385 insertions(+), 1 deletion(-) diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc index 5d560073d146ff..9f92be49a7a095 100644 --- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc +++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc @@ -106,6 +106,10 @@ struct xfs_sb xfs_lsn_t sb_lsn; uuid_t sb_meta_uuid; xfs_ino_t sb_metadirino; + xfs_rgnumber_t sb_rgcount; + xfs_rgblock_t sb_rgextents; + uint8_t sb_rgblklog; + uint8_t sb_pad[7]; }; ---- *sb_magicnum*:: @@ -413,6 +417,12 @@ to have a slightly higher level of redundancy over the shape of the inode btrees, and decreases the amount of time to compute the metadata B+tree preallocations at mount time. +| +XFS_SB_FEAT_RO_COMPAT_RTSB+ | +Realtime superblock. The first rt extent in rt group zero contains a superblock +header that can be used to identify the realtime device. See the section about +the xref:Realtime_Group_Superblocks[realtime group superblocks] for more +information. + |===== *sb_features_incompat*:: @@ -476,6 +486,10 @@ pointers] for more information. Metadata directory tree. See the section about the xref:Metadata_Directories[ metadata directory tree] for more information. +| +XFS_SB_FEAT_INCOMPAT_RTGROUPS+ | +Realtime allocation groups. See the section about the xref:Realtime_Groups[ +realtime groups] for more information. + |===== *sb_features_log_incompat*:: @@ -514,6 +528,23 @@ If the +XFS_SB_FEAT_RO_INCOMPAT_METADIR+ feature is set, this field points to the inode of the root directory of the metadata directory tree. This field is zero otherwise. +*sb_rgcount*:: +Count of realtime groups in the filesystem, if the ++XFS_SB_FEAT_INCOMPAT_RTGROUPS+ feature is enabled. + +*sb_rgextents*:: +Maximum number of realtime extents that can be contained within a realtime +group, if the +XFS_SB_FEAT_INCOMPAT_RTGROUPS+ feature is enabled. + +*sb_rgblklog*:: +If the +XFS_SB_FEAT_INCOMPAT_RTGROUPS+ feature is enabled, this is the log~2~ +value of +sb_rgextents+ * +sb_rextsize+ (rounded up). This value is used to +generate absolute block numbers defined in extent maps from the segmented ++xfs_rtblock_t+ values. + +*sb_pad[7]*:: +Zeroes, if the +XFS_SB_FEAT_INCOMPAT_RTGROUPS+ feature is enabled. + === xfs_db Superblock Example A filesystem is made on a single disk with the following command: diff --git a/design/XFS_Filesystem_Structure/common_types.asciidoc b/design/XFS_Filesystem_Structure/common_types.asciidoc index 51909be384e273..34cdfdaeccf848 100644 --- a/design/XFS_Filesystem_Structure/common_types.asciidoc +++ b/design/XFS_Filesystem_Structure/common_types.asciidoc @@ -43,7 +43,9 @@ Unsigned 64 bit raw filesystem block number. *xfs_rtblock_t*:: Unsigned 64 bit extent number in the xref:Real-time_Devices[real-time] -sub-volume. +sub-volume. If the +XFS_SB_FEAT_INCOMPAT_METADIR+ feature is enabled, these +values combine an xref:Realtime_Groups[rtgroup number] and block offset into +the realtime group. *xfs_fileoff_t*:: Unsigned 64 bit block offset into a file. diff --git a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc index 68c86d30ff8206..5f4d62201cbd67 100644 --- a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc +++ b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc @@ -21,6 +21,8 @@ of those inodes have been deallocated and may be reused by future features. [options="header"] |===== | Metadata File | Location +| xref:Real-Time_Bitmap_Inode[Realtime Bitmap] | /rtgroups/*.bitmap +| xref:Real-Time_Summary_Inode[Realtime Summary] | /rtgroups/*.summary |===== Metadata files are flagged by the +XFS_DIFLAG2_METADATA+ flag in the diff --git a/design/XFS_Filesystem_Structure/magic.asciidoc b/design/XFS_Filesystem_Structure/magic.asciidoc index 60952aeb876ff5..5da29b9ef9f3a8 100644 --- a/design/XFS_Filesystem_Structure/magic.asciidoc +++ b/design/XFS_Filesystem_Structure/magic.asciidoc @@ -45,9 +45,12 @@ relevant chapters. Magic numbers tend to have consistent locations: | +XFS_ATTR3_LEAF_MAGIC+ | 0x3bee | | xref:Leaf_Attributes[Leaf Attribute], v5 only | +XFS_ATTR3_RMT_MAGIC+ | 0x5841524d | XARM | xref:Remote_Values[Remote Attribute Value], v5 only | +XFS_RMAP_CRC_MAGIC+ | 0x524d4233 | RMB3 | xref:Reverse_Mapping_Btree[Reverse Mapping B+tree], v5 only +| +XFS_RTBITMAP_MAGIC+ | 0x424D505A | BMPZ | xref:Real-Time_Bitmap_Inode[Real-Time Bitmap], metadir only +| +XFS_RTSUMMARY_MAGIC+ | 0x53554D59 | SUMY | xref:Real-Time_Summary_Inode[Real-Time Summary], metadir only | +XFS_RTRMAP_CRC_MAGIC+ | 0x4d415052 | MAPR | xref:Real_time_Reverse_Mapping_Btree[Real-Time Reverse Mapping B+tree], v5 only | +XFS_REFC_CRC_MAGIC+ | 0x52334643 | R3FC | xref:Reference_Count_Btree[Reference Count B+tree], v5 only | +XFS_MD_MAGIC+ | 0x5846534d | XFSM | xref:Metadata_Dumps[Metadata Dumps] +| +XFS_RTSB_MAGIC+ | 0x46726F67 | Frog | xref:Realtime_Groups[Realtime Groups] |===== The magic numbers for log items are at offset zero in each log item, but items diff --git a/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc b/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc index 02ec0d12bb57e5..e28929907147b7 100644 --- a/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc +++ b/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc @@ -199,6 +199,8 @@ directory tree. [source, c] ---- enum xfs_metafile_type { + XFS_METAFILE_RTBITMAP, + XFS_METAFILE_RTSUMMARY, }; ---- diff --git a/design/XFS_Filesystem_Structure/realtime.asciidoc b/design/XFS_Filesystem_Structure/realtime.asciidoc index 11426e8fdb632d..3a72eb5175ad89 100644 --- a/design/XFS_Filesystem_Structure/realtime.asciidoc +++ b/design/XFS_Filesystem_Structure/realtime.asciidoc @@ -31,6 +31,146 @@ and bits per byte. This value is stored in +sb_rbmblocks+. The nblocks and extent array for the inode should match this. Each real time block gets its own bit in the bitmap. +If the +XFS_SB_FEAT_INCOMPAT_METADIR+ feature is enabled, each block of the +realtime bitmap file has a header of the following format: + +[source, c] +---- +struct xfs_rtbuf_blkinfo { + __be32 rt_magic; + __be32 rt_crc; + __be64 rt_owner; + __be64 rt_blkno; + __be64 rt_lsn; + uuid_t rt_uuid; +}; +---- + +*rt_magic*:: +Specifies the magic number for the rtbitmap block: ``BMPZ'' (0x424D505A). + +*rt_crc*:: +Checksum of the block. + +*rt_owner*:: +Specifies the inode number for the file that owns this block. + +*rt_blkno*:: +Disk address of this block. + +*rt_lsn*:: +Log sequence number of the last write to this block. + +*rt_uuid*:: +The UUID of this block, which must match either +sb_uuid+ or +sb_meta_uuid+ +depending on which features are set. + +After the block header, the bitmap data are encoded as be32 word values. + +=== xfs_db rtbitmap Example + +This example shows a real-time bitmap file from a freshly populated filesystem: + +---- +xfs_db> path -m /rtgroups/3.bitmap +xfs_db> p +core.magic = 0x494e +core.mode = 0100000 +core.version = 3 +core.format = 2 (extents) +core.metatype = 5 (rtbitmap) +core.uid = 0 +core.gid = 0 +core.nlinkv2 = 1 +core.projid_lo = 3 +core.projid_hi = 0 +core.nextents = 1 +core.atime.sec = Tue Oct 15 16:04:02 2024 +core.atime.nsec = 769675000 +core.mtime.sec = Tue Oct 15 16:04:02 2024 +core.mtime.nsec = 769675000 +core.ctime.sec = Tue Oct 15 16:04:02 2024 +core.ctime.nsec = 769681000 +core.size = 135168 +core.nblocks = 33 +core.extsize = 0 +core.naextents = 0 +core.forkoff = 24 +core.aformat = 1 (local) +core.dmevmask = 0 +core.dmstate = 0 +core.newrtbm = 0 +core.prealloc = 0 +core.realtime = 0 +core.immutable = 1 +core.append = 0 +core.sync = 1 +core.noatime = 1 +core.nodump = 1 +core.rtinherit = 0 +core.projinherit = 0 +core.nosymlinks = 0 +core.extsz = 0 +core.extszinherit = 0 +core.nodefrag = 1 +core.filestream = 0 +core.gen = 2653591217 +next_unlinked = null +v3.crc = 0x34a17119 (correct) +v3.change_count = 3 +v3.lsn = 0 +v3.flags2 = 0x38 +v3.cowextsize = 0 +v3.crtime.sec = Tue Oct 15 16:04:02 2024 +v3.crtime.nsec = 769675000 +v3.inumber = 33685633 +v3.uuid = a6575f59-1514-445e-883e-211b2c5a0f05 +v3.reflink = 0 +v3.cowextsz = 0 +v3.dax = 0 +v3.bigtime = 1 +v3.nrext64 = 1 +v3.metadata = 1 +u3.bmx[0] = [startoff,startblock,blockcount,extentflag] +0:[0,4210712,33,0] +a.sfattr.hdr.totsize = 27 +a.sfattr.hdr.count = 1 +a.sfattr.list[0].namelen = 8 +a.sfattr.list[0].valuelen = 12 +a.sfattr.list[0].root = 0 +a.sfattr.list[0].secure = 0 +a.sfattr.list[0].parent = 1 +a.sfattr.list[0].name = "0.bitmap" +a.sfattr.list[0].parent_dir.inumber = 33685632 +a.sfattr.list[0].parent_dir.gen = 142228546 +xfs_db> dblock 0 +xfs_db> p +magicnum = 0x424d505a +crc = 0xc8b10abf (correct) +owner = 33685633 +bno = 20902080 +lsn = 0x100007696 +uuid = a6575f59-1514-445e-883e-211b2c5a0f05 +rtwords[0-1011] = 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:0 10:0 11:0 12:0 13:0 +14:0 15:0 16:0 17:0 18:0 19:0 20:0 21:0xfffff800 22:0xffffffff 23:0xffffffff +24:0xffffffff 25:0xffffffff 26:0xffffffff 27:0xffffffff 28:0xffffffff +29:0xffffffff 30:0xffffffff 31:0xffffffff 32:0xffffffff +... +979:0xffffffff 980:0xffffffff 981:0xffffffff 982:0xffffffff 983:0xffffffff +984:0xffffffff 985:0xffffffff 986:0xffffffff 987:0xffffffff 988:0xffffffff +989:0xffffffff 990:0xffffffff 991:0xffffffff 992:0xffffffff 993:0xffffffff +994:0xffffffff 995:0xffffffff 996:0xffffffff 997:0xffffffff 998:0xffffffff +999:0xffffffff 1000:0xffffffff 1001:0xffffffff 1002:0xffffffff 1003:0xffffffff +1004:0xffffffff 1005:0xffffffff 1006:0xffffffff 1007:0xffffffff 1008:0xffffffff +1009:0xffffffff 1010:0xffffffff 1011:0xffffffff +---- + +From this example, we can clearly see that this is a bitmap file in the +metadata directory tree, and that it is the bitmap file for rtgroup 3. When we +access the first block in the bitmap file, we can clearly see the new block +header and that the first 179 extents are allocated. The bitmap words were +excerpted for brevity. + [[Real-Time_Summary_Inode]] == Free Space Summary Inode @@ -47,4 +187,208 @@ This data structure is not particularly space efficient, however it is a very fast way to provide the same data as the two free space B+trees for regular files since the space is preallocated and metadata maintenance is minimal. +If the +XFS_SB_FEAT_INCOMPAT_METADIR+ feature is enabled, each block of the +realtime summary file has the same header as rtbitmap file blocks. However, +the magic number will be ``SUMY'' (0x53554D59). After the block header, the +summary counts are encoded as be32 integers. + +=== xfs_db rtsummary Example + +This example shows a real-time summary file from a freshly populated filesystem: + +---- +xfs_db> path -m /rtgroups/3.summary +xfs_db> p +core.magic = 0x494e +core.mode = 0100000 +core.version = 3 +core.format = 2 (extents) +core.metatype = 6 (rtsummary) +core.uid = 0 +core.gid = 0 +core.nlinkv2 = 1 +core.projid_lo = 3 +core.projid_hi = 0 +core.nextents = 1 +core.atime.sec = Tue Oct 15 16:04:02 2024 +core.atime.nsec = 769694000 +core.mtime.sec = Tue Oct 15 16:04:02 2024 +core.mtime.nsec = 769694000 +core.ctime.sec = Tue Oct 15 16:04:02 2024 +core.ctime.nsec = 769699000 +core.size = 4096 +core.nblocks = 1 +core.extsize = 0 +core.naextents = 0 +core.forkoff = 24 +core.aformat = 1 (local) +core.dmevmask = 0 +core.dmstate = 0 +core.newrtbm = 0 +core.prealloc = 0 +core.realtime = 0 +core.immutable = 1 +core.append = 0 +core.sync = 1 +core.noatime = 1 +core.nodump = 1 +core.rtinherit = 0 +core.projinherit = 0 +core.nosymlinks = 0 +core.extsz = 0 +core.extszinherit = 0 +core.nodefrag = 1 +core.filestream = 0 +core.gen = 519466891 +next_unlinked = null +v3.crc = 0x54fc58d0 (correct) +v3.change_count = 3 +v3.lsn = 0 +v3.flags2 = 0x38 +v3.cowextsize = 0 +v3.crtime.sec = Tue Oct 15 16:04:02 2024 +v3.crtime.nsec = 769694000 +v3.inumber = 33685634 +v3.uuid = a6575f59-1514-445e-883e-211b2c5a0f05 +v3.reflink = 0 +v3.cowextsz = 0 +v3.dax = 0 +v3.bigtime = 1 +v3.nrext64 = 1 +v3.metadata = 1 +u3.bmx[0] = [startoff,startblock,blockcount,extentflag] +0:[0,4210703,1,0] +a.sfattr.hdr.totsize = 28 +a.sfattr.hdr.count = 1 +a.sfattr.list[0].namelen = 9 +a.sfattr.list[0].valuelen = 12 +a.sfattr.list[0].root = 0 +a.sfattr.list[0].secure = 0 +a.sfattr.list[0].parent = 1 +a.sfattr.list[0].name = "0.summary" +a.sfattr.list[0].parent_dir.inumber = 33685632 +a.sfattr.list[0].parent_dir.gen = 142228546 +xfs_db> dblock 0 +xfs_db> p +magicnum = 0x53554d59 +crc = 0x473340a8 (correct) +owner = 33685634 +bno = 20902008 +lsn = 0x100007696 +uuid = a6575f59-1514-445e-883e-211b2c5a0f05 +suminfo[0-1011] = 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:0 10:0 11:0 12:0 13:0 +14:0 15:0 16:0 17:0 18:0 19:0 20:0 21:0 22:0 23:0 24:0 25:0 26:0 27:0 28:0 29:0 +30:0 31:0 32:0 +... +618:0 619:0 620:0 621:0 622:0 623:0 624:0 625:0 626:0 627:1 628:0 629:0 630:0 +... +979:0 980:0 981:0 982:0 983:0 984:0 985:0 986:0 987:0 988:0 989:0 990:0 991:0 +992:0 993:0 994:0 995:0 996:0 997:0 998:0 999:0 1000:0 1001:0 1002:0 1003:0 +1004:0 1005:0 1006:0 1007:0 1008:0 1009:0 1010:0 1011:0 +---- + +From this example, we can clearly see that this is a summary file in the +metadata directory tree, and that it is the summary file for rtgroup 3. When +we access the first block in the summary file, we can clearly see the new block +header and the nonzero counter for the one large free extent in this group. +The summary counts were excerpted for brevity. + +[[Realtime_Groups]] +== Realtime Groups + +To reduce metadata contention for space allocation and remapping activities +being applied to realtime files, the realtime volume can be split into +allocation groups, just like the data volume. The free space information is +still contained in a single file that applies to the entire volume. + +Each realtime allocation group can contain up to (2^31^ - 1) filesystem blocks, +regardless of the underlying realtime extent size. + +Each realtime group has the following characteristics: + + * Group 0 has a super block describing overall filesystem info + * Free space bitmap + * Summary of free space + +The free space metadata are the same as described in the previous sections, +except that their scope covers only a single rtgroup. The other structures are +expanded upon in the following sections. + +[[Realtime_Group_Superblocks]] +=== Superblocks + +The first block of each realtime group contains a superblock. These fields +must match their counterparts in the filesystem superblock on the data device. + +[source, c] +---- +struct xfs_rtsb { + __be32 rsb_magicnum; + __le32 rsb_crc; + + __be32 rsb_pad; + unsigned char rsb_fname[XFSLABEL_MAX]; + + uuid_t rsb_uuid; + uuid_t rsb_meta_uuid; + + /* must be padded to 64 bit alignment */ +}; +---- + +*rsb_magicnum*:: +Identifies the filesystem. Its value is +XFS_RTSB_MAGIC+ ``Frog'' (0x46726F67). + +*rsb_crc*:: +Superblock checksum. + +*rsb_pad*:: +Must be zero. + +*rsb_fname[12]*:: +Name for the filesystem. This matches +sb_fname+ in the primary superblock. + +*rsb_uuid*:: +UUID (Universally Unique ID) for the filesystem. This matches +sb_uuid+ in the +primary superblock. + +*rsb_meta_uuid*:: +Metadata UUID for the filesystem. This matches +sb_meta_uuid+ in the primary +superblock. + +==== xfs_db rtgroup Superblock Example + +A filesystem is made on a multidisk filesystem with the following command: + +---- +# mkfs.xfs -r rtgroups=1,rgcount=4,rtdev=/dev/sdb /dev/sda -f +meta-data=/dev/sda isize=512 agcount=4, agsize=1298176 blks + = sectsz=512 attr=2, projid32bit=1 + = crc=1 finobt=1, sparse=1, rmapbt=1 + = reflink=1 bigtime=1 inobtcount=1 nrext64=1 + = metadir=1 +data = bsize=4096 blocks=5192704, imaxpct=25 + = sunit=0 swidth=0 blks +naming =version 2 bsize=4096 ascii-ci=0, ftype=1 +log =internal log bsize=4096 blocks=16384, version=2 + = sectsz=512 sunit=0 blks, lazy-count=1 +realtime =/dev/sdb extsz=4096 blocks=5192704, rtextents=5192704 + = rgcount=5 rgsize=1048576 extents +---- + +And in xfs_db, inspecting the realtime group superblock and then the regular +superblock: + +---- +# xfs_db -R /dev/sdb /dev/sda +xfs_db> rtsb +xfs_db> print +magicnum = 0x46726f67 +crc = 0x759a62d4 (correct) +pad = 0 +fname = "\000\000\000\000\000\000\000\000\000\000\000\000" +uuid = 7e55b909-8728-4d69-a1fa-891427314eea +meta_uuid = 7e55b909-8728-4d69-a1fa-891427314eea +---- + include::rtrmapbt.asciidoc[] From patchwork Wed Nov 6 19:19:25 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13865341 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3FB7209F30 for ; Wed, 6 Nov 2024 19:19:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730920768; cv=none; b=q9JmIP8vHqvbscMlSGr7siA7E8b7Lpn+4AMdXQxoqJ+48bRextFl7btPDjKYCDxO9rG++jijyyP1QQuX/vuCt1IMarck58E0Yb26rhVJC+pSqN5+JtjctKqJRpLhQs+49siXxGuTiJ8FYXMSQUBZfuHtiSDWF61kfGCZXF2wnvk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730920768; c=relaxed/simple; bh=9kfW7BfX3FdAXkVGFEXR5iCW8wddquKx2RWw/VzvHL0=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jXuUsgiUbBFaE66XUqUOeZOhAu3ltXedLtoI4ByvM77Rm7VpZSFmKYi4qzhP14GQyZZn0VweWpb02ah/V1UGFzmzpQdo66K/rIl/fS5RiZADpWrBRs6xZh6CMMpiWHmZJj8WZQSaO9F0RlMv335rwFHBQTNDh/t5q9F1BUjNWIQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O0gUYqM8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O0gUYqM8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34884C4CEC6; Wed, 6 Nov 2024 19:19:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730920766; bh=9kfW7BfX3FdAXkVGFEXR5iCW8wddquKx2RWw/VzvHL0=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=O0gUYqM8MQgA9gKPIxvB9gewT+VuGWtMh+8KiSZEyGqghWw7aXCkd3tgUsf+FWolR rcoqqjbIDHGQvL5J8dkDKpFZAXO21NIcF0lCNmqXWQ2jxfjCbA+EYZz0J3WGRXnsUu vGEIHS3fFUQL7VYZaB3/OmwFSOK1XC3QUFr+8wLYjD1wWWEbd0tVq5efUlYl3tx5tS iIhP9IifHm+lv/GPCC6+/RzzPOREAywiKW8V9ZnXhJWRH5vfTsN/memcFPMRlbRXj9 1b0A+XjJvtL1p1NseD5S778s1oLTLaUGEfmJT7T25vrzhiK5pbPPUMeQadvswmwKY0 YAYH3mCDJFedg== Date: Wed, 06 Nov 2024 11:19:25 -0800 Subject: [PATCH 3/4] design: document metadata directory tree quota changes From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <173092059744.2883258.7281058243421376662.stgit@frogsfrogsfrogs> In-Reply-To: <173092059696.2883258.7093773656482973762.stgit@frogsfrogsfrogs> References: <173092059696.2883258.7093773656482973762.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Document the changes to the ondisk quota metadata that came in with metadata directory trees. Signed-off-by: Darrick J. Wong --- .../allocation_groups.asciidoc | 3 +++ .../internal_inodes.asciidoc | 3 +++ .../XFS_Filesystem_Structure/ondisk_inode.asciidoc | 3 +++ 3 files changed, 9 insertions(+) diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc index 9f92be49a7a095..86daf9cdd30a0c 100644 --- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc +++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc @@ -293,6 +293,9 @@ Quota flags. It can be a combination of the following flags: | +XFS_PQUOTA_CHKD+ | Project quotas have been checked. |===== +If the +XFS_SB_FEAT_INCOMPAT_METADIR+ feature is enabled, the +sb_qflags+ field +will persist across mounts if no quota mount options are provided. + *sb_flags*:: Miscellaneous flags. diff --git a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc index 5f4d62201cbd67..40eb57233ce7c0 100644 --- a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc +++ b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc @@ -21,6 +21,9 @@ of those inodes have been deallocated and may be reused by future features. [options="header"] |===== | Metadata File | Location +| xref:Quota_Inodes[User Quota] | /quota/user +| xref:Quota_Inodes[Group Quota] | /quota/group +| xref:Quota_Inodes[Project Quota] | /quota/project | xref:Real-Time_Bitmap_Inode[Realtime Bitmap] | /rtgroups/*.bitmap | xref:Real-Time_Summary_Inode[Realtime Summary] | /rtgroups/*.summary |===== diff --git a/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc b/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc index e28929907147b7..6e52e5fd3d6c1e 100644 --- a/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc +++ b/design/XFS_Filesystem_Structure/ondisk_inode.asciidoc @@ -199,6 +199,9 @@ directory tree. [source, c] ---- enum xfs_metafile_type { + XFS_METAFILE_USRQUOTA, + XFS_METAFILE_GRPQUOTA, + XFS_METAFILE_PRJQUOTA, XFS_METAFILE_RTBITMAP, XFS_METAFILE_RTSUMMARY, }; From patchwork Wed Nov 6 19:19:41 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13865342 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39FE9208204 for ; Wed, 6 Nov 2024 19:19:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730920782; cv=none; b=RqcCP50aJfCzsR4fPbDNwEy+3+ufthUOmQJdY7S/62+u0t3apTJ3Re8v0o7z6c7z8vIn/EgZp7JvYKkw5dD6A+/JNdNOWY2L7uX7f3HHTkXd3X6qGVzYRbyWQUD3j8eV9tlW6LwNjoSaUHCY4bTaQhXPKa4seoOvsL33Q5CtF4c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730920782; c=relaxed/simple; bh=ilJDkyzt0wvocyOQ1Ctp21j3SclhLFUP3KAWAitX674=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=LygPRfp7vBwx4oPfOaWYQrOUXua4OKiY1OmlZTabXGUDlHNVQm7pRDMlv76vUEIPKZh+5hV0JUnPAich7bSseTT2Kz4f4MX/eCDs53DmWVjp490Unaa4dJ68eKAvmGEFUFdEy29dImf5SysmBgH3A3CYk3z0eRJkDsKvApGkqEA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pJR0uXSA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pJR0uXSA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4F04C4CEC6; Wed, 6 Nov 2024 19:19:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730920781; bh=ilJDkyzt0wvocyOQ1Ctp21j3SclhLFUP3KAWAitX674=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=pJR0uXSASYgAYSRqiMNKs7sJtP5uOZuFC2E6qcYTR+6iUt852CaNAgLBOgY6ztBO7 GOWJEbTziIwCwO8s+BeQJ2k3G7WkwjFqKNioUdx5cHUkJ3bmXJ2/DvPFU+mUXNM3kk 8LF7Euj1d8rYf01mkXsvDENAbVFs4Oewa7ULt+gpuBXg0FQYb3vZHDgTPv0IJm8A+J 2McXNQ3KKoSg2pZ9FmxqxdYnfHWXXlPlTQ9oIlkE+3ZTO73igSGwa5rtY8iDOolBN8 AYk39axmTrKlhdcqL0U30pK8cbZBEsYcQflenaijB2b2apGhOJ96Q96URGGJebLXl/ DDvnbR35Use4w== Date: Wed, 06 Nov 2024 11:19:41 -0800 Subject: [PATCH 4/4] design: update metadump v2 format to reflect rt dumps From: "Darrick J. Wong" To: djwong@kernel.org Cc: linux-xfs@vger.kernel.org, hch@lst.de Message-ID: <173092059759.2883258.10101323739690762194.stgit@frogsfrogsfrogs> In-Reply-To: <173092059696.2883258.7093773656482973762.stgit@frogsfrogsfrogs> References: <173092059696.2883258.7093773656482973762.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Update the metadump v2 format documentation to add realtime device dumps. Signed-off-by: Darrick J. Wong --- design/XFS_Filesystem_Structure/metadump.asciidoc | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/design/XFS_Filesystem_Structure/metadump.asciidoc b/design/XFS_Filesystem_Structure/metadump.asciidoc index a32d6423ea6e75..226622c0d2f20e 100644 --- a/design/XFS_Filesystem_Structure/metadump.asciidoc +++ b/design/XFS_Filesystem_Structure/metadump.asciidoc @@ -119,7 +119,16 @@ Dump contains external log contents. |===== *xmh_incompat_flags*:: -Must be zero. +A combination of the following flags: + +.Metadump v2 incompat flags +[options="header"] +|===== +| Flag | Description +| +XFS_MD2_INCOMPAT_RTDEVICE+ | +Dump contains realtime device contents. + +|===== *xmh_reserved*:: Must be zero. @@ -143,6 +152,7 @@ Bits 55-56 determine the device from which the metadata dump data was extracted. | Value | Description | 0 | Data device | 1 | External log +| 2 | Realtime device |===== The lower 54 bits determine the device address from which the dump data was