On Tue, May 29, 2018 at 01:14:22PM +1000, Dave Chinner wrote: > On Thu, May 17, 2018 at 08:53:47PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > > Now that we've plumbed in the ability to construct a list of dead btree > > blocks following a repair, add more helpers to dispose of them. This is > > done by examining the rmapbt -- if the btree was the only owner we can > > free the block, otherwise it's crosslinked and we can only remove the > > rmapbt record. > > > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > --- > > v2: document the design of how old btree block disposal is supposed to > > work and document some of the limitations of the buffer cache that > > we can't fix here, and reduce perag_get/put traffic > > Yup, I can accept those limitations for the initial implementation. > Gotta leave something for you to work on once it's been merged, > right? Yeah. I'd spec'd out adding a bitmap to each AG's xfs_buf cache to track non-stale cached buffers and scream if someone tries to add an overlapping buffer, but then started talking to Dan last week about connecting XFS to pmem poison notifications. If the metadata block using the poisoned pmem is cached in dram then we'd want to find the associated xfs_buf and write it back out. For that we'd need full block -> buf mapping abilities (and not just a bitmap), which will likely bloat the radix tree significantly. This became a mess of ink in my notebook so I gave up, for now. --D > Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> > > -- > Dave Chinner > david@xxxxxxxxxxxxx > -- > 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 -- 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
