Skip to contentSkip to conversation

xfs: make iomap_begin functions trim iomaps consistently

PATCH In review Darrick J. Wong 2 participants 3 messages Dec 6, 2017 – Dec 7, 2017 XFS filesystem

lore
Share & tools
lore

Darrick J. Wong

author
#0 lore raw

PATCH 1/1 xfs: make iomap_begin functions trim iomaps consistently

From: Darrick J. Wong <[email protected]>

Historically, the XFS iomap_begin function only returned mappings for exactly the range queried, i.e. it doesn't do XFS_BMAPI_ENTIRE lookups. The current vfs iomap consumers are only set up to deal with trimmed mappings. xfs_xattr_iomap_begin does BMAPI_ENTIRE lookups, which is inconsistent with the current iomap usage. Remove the flag so that both iomap_begin functions behave the same way.

FWIW this also fixes a behavioral regression in xattr FIEMAP that was introduced in 4.8 wherein attr fork extents are no longer trimmed like they used to be.

Signed-off-by Darrick J. Wong <[email protected]>
---
 fs/xfs/xfs_iomap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/xfs/xfs_iomap.c +1 -1
index 33eb4fb..7ab52a8 100644
@@ -1213,7 +1213,7 @@ xfs_xattr_iomap_begin(
 
 	ASSERT(ip->i_d.di_aformat != XFS_DINODE_FMT_LOCAL);
 	error = xfs_bmapi_read(ip, offset_fsb, end_fsb - offset_fsb, &imap,
-			       &nimaps, XFS_BMAPI_ENTIRE | XFS_BMAPI_ATTRFORK);
+			       &nimaps, XFS_BMAPI_ATTRFORK);
 out_unlock:
 	xfs_iunlock(ip, lockmode);
Reviewed-by on v1 1/1
#1 lore raw
Quoted 9 lines · Darrick J. Wong

From: Darrick J. Wong <[email protected]>

Historically, the XFS iomap_begin function only returned mappings for exactly the range queried, i.e. it doesn't do XFS_BMAPI_ENTIRE lookups. The current vfs iomap consumers are only set up to deal with trimmed mappings. xfs_xattr_iomap_begin does BMAPI_ENTIRE lookups, which is inconsistent with the current iomap usage. Remove the flag so that both iomap_begin functions behave the same way.

Quoted 3 lines

FWIW this also fixes a behavioral regression in xattr FIEMAP that was introduced in 4.8 wherein attr fork extents are no longer trimmed like they used to be.

I would still prefer to trim in the iomap code. But I'll need to find some time to look into that, so until then here is my reluctant ACK:

Reviewed-by Christoph Hellwig <[email protected]>
author
#2 lore raw
Quoted 10 lines · Christoph Hellwig
Quoted 9 lines · Darrick J. Wong

From: Darrick J. Wong <[email protected]>

Historically, the XFS iomap_begin function only returned mappings for exactly the range queried, i.e. it doesn't do XFS_BMAPI_ENTIRE lookups. The current vfs iomap consumers are only set up to deal with trimmed mappings. xfs_xattr_iomap_begin does BMAPI_ENTIRE lookups, which is inconsistent with the current iomap usage. Remove the flag so that both iomap_begin functions behave the same way.

Quoted 6 lines
Quoted 3 lines

FWIW this also fixes a behavioral regression in xattr FIEMAP that was introduced in 4.8 wherein attr fork extents are no longer trimmed like they used to be.

I would still prefer to trim in the iomap code. But I'll need to find some time to look into that, so until then here is my reluctant ACK:

I started looking into that -- the iomap trimming is easy, but the data fork iomap_begin (with a BMAPI_ENTIRE lookup) gets tripped up on trimming the iomap around shared extents, because if we have an extent:
(R = regular, S = shared block)

01234567
RRRSSSSS

and we ask for iomap_begin(off=3, len=5) we return RRR (because we trim to the first change in sharedness status) and not the SSSSS we expect and then everything goes nuts.... so in the meantime we'll just restore the old XFS behavior and bikeshed fiemap^W^Wclean it up later.

--D

Quoted 5 lines
Reviewed-by Christoph Hellwig <[email protected]>

--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html