Hi, I've been playing around with deferring AGFL block frees and noticed something funky going on with xfs_bmap_add_free() and owner info. We pass the extent owner info to xfs_bmap_add_free() in various places to transfer this info to the deferred free processing context. Subsequently, xfs_trans_free_extent() -> ... -> xfs_free_ag_extent() uses the owner info to remove the rmapbt entry associated with the extent. The rmapbt update occurs at the time the extent is freed. If the system crashes immediately after the initial transaction commits, however, EFI recovery calls xfs_trans_free_extent() with an "unknown" owner. I see a reference to using a "wildcard" in this context in some of the old rmapbt commits, but it looks like this codepath skips the rmapbt update altogether if oi_owner == XFS_RMAP_OWN_UNKNOWN. A quick test that shuts down the fs immediately after a transaction commits that logs an EFI for a freed inode chunk leaves the fs inconsistent after log recovery, with a bit of a cryptic message from repair: unknown block state, ag 0, block 24 It does look like the associated rmapbt entry still exists in the tree even though the extent has been freed (from xfs_db -c fsmap): 5: 0/24 len 8 owner -7 offset 0 bmbt 0 attrfork 0 extflag 0 So what is supposed to be going on here? Should the rmapbt entry be removed unconditionally during recovery, or should a separate rmapbt update item be deferred (as in the bunmapi case, for example) rather than passing oinfo along with the TYPE_FREE deferred item? Or something else entirely..? Brian -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
