diff options
author | Darrick J. Wong <djwong@kernel.org> | 2025-04-15 03:33:45 +0300 |
---|---|---|
committer | Carlos Maiolino <cem@kernel.org> | 2025-04-16 13:56:10 +0300 |
commit | c6f1401b1d5fb3b83bd16ba8a0f89a8b1c805993 (patch) | |
tree | 3552eac0742c55977040d738dc20d16910d9c080 /rust/helpers/err.c | |
parent | 1c406526bd84f1e0bd4bb4b50c6eeba0b135765a (diff) | |
download | linux-c6f1401b1d5fb3b83bd16ba8a0f89a8b1c805993.tar.xz |
xfs: fix fsmap for internal zoned devices
Filesystems with an internal zoned rt section use xfs_rtblock_t values
that are relative to the start of the data device. When fsmap reports
on internal rt sections, it reports the space used by the data section
as "OWN_FS".
Unfortunately, the logic for resuming a query isn't quite right, so
xfs/273 fails because it stress-tests GETFSMAP with a single-record
buffer. If we enter the "report fake space as OWN_FS" block with a
nonzero key[0].fmr_length, we should add that to key[0].fmr_physical
and recheck if we still need to emit the fake record. We should /not/
just return 0 from the whole function because that prevents all rmap
record iteration.
If we don't enter that block, the resumption is still wrong.
keys[*].fmr_physical is a reflection of what we copied out to userspace
on a previous query, which means that it already accounts for rgstart.
It is not correct to add rtstart_daddr when computing start_rtb or
end_rtb, so stop that.
While we're at it, add a xfs_has_zoned to make it clear that this is a
zoned filesystem thing.
Fixes: e50ec7fac81aa2 ("xfs: enable fsmap reporting for internal RT devices")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Diffstat (limited to 'rust/helpers/err.c')
0 files changed, 0 insertions, 0 deletions