Re: [PATCH] btrfs: fix possible infinite loop in data async reclaim

[David Sterba <dsterba@suse.cz>]

On Tue, Aug 25, 2020 at 04:56:59PM -0400, Josef Bacik wrote:
> Dave reported an issue where generic/102 would sometimes hang.  This
> turned out to be because we'd get into this spot where we were no longer
> making progress on data reservations because our exit condition was not
> met.  The log is basically
> 
> while (!space_info->full && !list_empty(&space_info->tickets))
> 	flush_space(space_info, flush_state);
> 
> where flush state is our various flush states, but doesn't include
> ALLOC_CHUNK_FORCE.  This is because we actually lead with allocating
> chunks, and so the assumption was that once you got to the actual
> flushing states you could no longer allocate chunks.  This was a stupid
> assumption, because you could have deleted block groups that would be
> reclaimed by a transaction commit, thus unsetting space_info->full.
> This is essentially what happens with generic/102, and so sometimes
> you'd get stuck in the flushing loop because we weren't allocating
> chunks, but flushing space wasn't giving us what we needed to make
> progress.
> 
> Fix this by adding ALLOC_CHUNK_FORCE to the end of our flushing states,
> that way we will eventually bail out because we did end up with
> space_info->full if we free'd a chunk previously.  Otherwise, as is the
> case for this test, we'll allocate our chunk and continue on our happy
> merry way.
> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

Thanks. As the flushing states are added one by one at the end of the
series, I'll add it as a separate patch. Folding it to some other patch
would lose a bit more of information that's in the changelog, so this
leaves a short window where the 102 hang could happen but again the
flushing sequence is not switched at once.