Re: [PATCH v3 20/35] xfs: introduce XFS_FSVERITY_REGION_START constant

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Feb 18, 2026 at 12:19:20AM +0100, Andrey Albershteyn wrote:
> This is location of fsverity metadata in the file. This offset is used

"...in the ondisk file."

> to store data on disk. When metadata is read into pagecache they are
> shifted to the offset returned by fsverity_metadata_offset().
> 
> Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>

(should all the ondisk format changes go in one patch?)

--D

> ---
>  fs/xfs/libxfs/xfs_fs.h | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/fs/xfs/libxfs/xfs_fs.h b/fs/xfs/libxfs/xfs_fs.h
> index 12463ba766da..e9c92bc0e64b 100644
> --- a/fs/xfs/libxfs/xfs_fs.h
> +++ b/fs/xfs/libxfs/xfs_fs.h
> @@ -1106,4 +1106,28 @@ enum xfs_device {
>  #define BBTOB(bbs)	((bbs) << BBSHIFT)
>  #endif
>  
> +/*
> + * Merkle tree and fsverity descriptor location on disk, in bytes. While this
> + * offset is huge, when data is read into pagecache iomap uses offset returned
> + * by fsverity_metadata_offset(), which is just beyound EOF.
> + *
> + * At maximum of 8 levels with 128 hashes per block (32 bytes SHA-256) maximum
> + * tree size is ((128^8 − 1)/(128 − 1)) = 567*10^12 blocks. This should fit in 53
> + * bits address space.
> + *
> + * At this Merkle tree size we can cover 295EB large file. This is much larger
> + * than the currently supported file size.
> + *
> + * For sha512 the largest file we can cover ends at 1 << 50 offset, this is also
> + * good.
> + *
> + * The metadata is placed as follows:
> + *
> + *	[merkle tree...][descriptor.............desc_size]
> + *	^ (1 << 53)     ^ (block border)                 ^ (end of the block)
> + *	                ^--------------------------------^
> + *	                Can be FS_VERITY_MAX_DESCRIPTOR_SIZE
> + */
> +#define XFS_FSVERITY_REGION_START ((loff_t)1ULL << 53)
> +
>  #endif	/* __XFS_FS_H__ */
> -- 
> 2.51.2
> 
>