@@ -1582,6 +1582,7 @@ xfs_alloc_ag_vextent_small(
xfs_extlen_t *flenp, /* result length */
int *stat) /* status: 0-freelist, 1-normal/none */
{
+ struct xfs_owner_info oinfo;
int error;
xfs_agblock_t fbno;
xfs_extlen_t flen;
@@ -1624,6 +1625,18 @@ xfs_alloc_ag_vextent_small(
error0);
args->wasfromfl = 1;
trace_xfs_alloc_small_freelist(args);
+
+ /*
+ * If we're feeding an AGFL block to something that
+ * doesn't live in the free space, we need to clear
+ * out the OWN_AG rmap.
+ */
+ xfs_rmap_ag_owner(&oinfo, XFS_RMAP_OWN_AG);
+ error = xfs_rmap_free(args->tp, args->agbp, args->agno,
+ fbno, 1, &oinfo);
+ if (error)
+ goto error0;
+
*stat = 0;
return 0;
}
[resend, cc list this time] I ftrace'd the rmap code while trying to repro the g/299 assert you saw. Eventually I got it to reproduce and it looks like a block would go onto the AGFL and we'd add an OWN_AG rmap for the block. ~20s later the block mysteriously ends up being mapped in a second time as some inode's BMBT block without the OWN_AG rmap being removed. So I looked around for anything that grabbed a block off the AGFL and noticed that the regular allocation function can do that if we get really tight on space. I also noticed that it doesn't remove the OWN_AG rmap, nor does it credit the per-AG reservation for the block it used. So here's a test patch that updates the rmap. (The per-AG stuff is in the reflink patchset so we don't need it here.) --- When we're really tight on space, xfs_alloc_ag_vextent_small() can allocate a block from the AGFL and give it to the caller. Since the caller is never the AGFL-fixing method, we must remove the OWN_AG reverse mapping because it will clash with whatever rmap the caller wants to set up. This bug was discovered by running generic/299 repeatedly. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> --- fs/xfs/libxfs/xfs_alloc.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)