On Wed, Jan 18, 2023 at 04:35:13PM -0500, Josef Bacik wrote: > There was a recent regression in btrfs/177 that started happening with > the size class patches. This however isn't a regression introduced by > those patches, but rather the bug was uncovered by a change in behavior > in these patches. The patches triggered more chunk allocations in the > ^free-space-tree case, which uncovered a race with device shrink. > > The problem is we will set the device total size to the new size, and > use this to find a hole for a device extent. However during shrink we > may have device extents allocated past this range, so we could > potentially find a hole in a range past our new shrink size. We don't > actually limit our found extent to the device size anywhere, we assume > that we will not find a hole past our device size. This isn't true with > shrink as we're relocating block groups and thus creating holes past the > device size. > > Fix this by making sure we do not search past the new device size, and > if we wander into any device extents that start after our device size > simply break from the loop and use whatever hole we've already found. > > cc: stable@xxxxxxxxxxxxxxx > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> Added to misc-next, thanks.
