>> [1] >> from to extents blocks pct >> 1 1 155759 155759 0.00 >> 2 3 1319 3328 0.00 >> 4 7 13153 56265 0.00 >> 8 15 152663 1752813 0.03 >> 16 31 143626908 4019133338 60.17 > > There's your problem. 143 million small free space extents totalling > 4TB of free space. That's going to require (roughly speaking) > somewhere between 3-500,000 4k btree leaf blocks to index. i.e a > footprint of 10-20GB of metadata. > > Even accounting for it being evenly spread across 50AGs, that's > still a 5-10k of btree blocks per free space btree per AG, and so if > that's not in cache when we end up doing a linear search for a near > block of a size that falls into this bucket, it's going to get stuck > reading btree leaf siblings from disk synchronously.... > > Perhaps this "near block" search needs to terminate after at a > certain search radius, similar to how the old AGI btree searches > during inode allocation were terminated after a certain radius of > allocated inode clusters were searched for free inodes.... Thank you for your response, Dave, this makes sense. Alex. -- 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
