]> www.infradead.org Git - users/hch/xfs.git/commit
xfs: clean up xfs_getfsmap_helper arguments
authorChristoph Hellwig <hch@lst.de>
Mon, 23 Sep 2024 20:41:06 +0000 (13:41 -0700)
committerDarrick J. Wong <djwong@kernel.org>
Wed, 9 Oct 2024 23:26:44 +0000 (16:26 -0700)
commit560f6f4be2bf46a87d184e101253610c4878854e
tree6ac194317839bbaf7249689399df986c11069e7c
parent65ac90f787826b730722b9750aa3f1bb8ee41dda
xfs: clean up xfs_getfsmap_helper arguments

The calling conventions for xfs_getfsmap_helper are confusing -- callers
pass in an rmap record, but they must also supply startblock and
blockcount in daddr units.  This was bolted onto the original fsmap
implementation so that we could report *something* for realtime
volumes, which do not support rmap and hence can draw only from the rt
free space bitmap.  Free space on the rt volume can be more than 2^32
fsblocks long, which means that we can't use the rmap startblock or
blockcount fields.

This is confusing for callers, because they must supplying redundant
data, but not all of it is used.  Streamline this by creating a separate
fsmap irec structure that contains exactly the data we need, once.

Note that we actually do need rm_startblock for rmap key comparisons
when we're actually querying an rmap btree, so leave that field but
document why it's there.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
fs/xfs/xfs_fsmap.c
fs/xfs/xfs_fsmap.h
fs/xfs/xfs_trace.h