• Josef Bacik's avatar
    Btrfs: fix possible softlockup in the allocator · 1cdda9b8
    Josef Bacik authored
    Like the cluster allocating stuff, we can lockup the box with the normal
    allocation path.  This happens when we
    
    1) Start to cache a block group that is severely fragmented, but has a decent
    amount of free space.
    2) Start to commit a transaction
    3) Have the commit try and empty out some of the delalloc inodes with extents
    that are relatively large.
    
    The inodes will not be able to make the allocations because they will ask for
    allocations larger than a contiguous area in the free space cache.  So we will
    wait for more progress to be made on the block group, but since we're in a
    commit the caching kthread won't make any more progress and it already has
    enough free space that wait_block_group_cache_progress will just return.  So,
    if we wait and fail to make the allocation the next time around, just loop and
    go to the next block group.  This keeps us from getting stuck in a softlockup.
    Thanks,
    Signed-off-by: default avatarJosef Bacik <jbacik@redhat.com>
    Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
    1cdda9b8
extent-tree.c 195 KB