btrfs: fix ssd_spread overallocation · Pull Request !6031 · anolis/cloud-kernel

bugzilla: https://bugzilla.openanolis.cn/show_bug.cgi?id=27250

1. btrfs: fix ssd_spread overallocation

[ Upstream commit 807d9023e75fc20bfd6dd2ac0408ce4af53f1648 ]
    
    If the ssd_spread mount option is enabled, then we run the so called
    clustered allocator for data block groups. In practice, this results in
    creating a btrfs_free_cluster which caches a block_group and borrows its
    free extents for allocation.
    
    Since the introduction of allocation size classes in 6.1, there has been
    a bug in the interaction between that feature and ssd_spread.
    find_free_extent() has a number of nested loops. The loop going over the
    allocation stages, stored in ffe_ctl->loop and managed by
    find_free_extent_update_loop(), the loop over the raid levels, and the
    loop over all the block_groups in a space_info. The size class feature
    relies on the block_group loop to ensure it gets a chance to see a
    block_group of a given size class.  However, the clustered allocator
    uses the cached cluster block_group and breaks that loop. Each call to
    do_allocation() will really just go back to the same cached block_group.
    Normally, this is OK, as the allocation either succeeds and we don't
    want to loop any more or it fails, and we clear the cluster and return
    its space to the block_group.
    
    But with size classes, the allocation can succeed, then later fail,
    outside of do_allocation() due to size class mismatch. That latter
    failure is not properly handled due to the highly complex multi loop
    logic. The result is a painful loop where we continue to allocate the
    same num_bytes from the cluster in a tight loop until it fails and
    releases the cluster and lets us try a new block_group. But by then, we
    have skipped great swaths of the available block_groups and are likely
    to fail to allocate, looping the outer loop. In pathological cases like
    the reproducer below, the cached block_group is often the very last one,
    in which case we don't perform this tight bg loop but instead rip
    through the ffe stages to LOOP_CHUNK_ALLOC and allocate a chunk, which
    is now the last one, and we enter the tight inner loop until an
    allocation failure. Then allocation succeeds on the final block_group
    and if the next allocation is a size mismatch, the exact same thing
    happens again.
    
    Triggering this is as easy as mounting with -o ssd_spread and then
    running:
    
      mount -o ssd_spread $dev $mnt
      dd if=/dev/zero of=$mnt/big bs=16M count=1 &>/dev/null
      dd if=/dev/zero of=$mnt/med bs=4M count=1 &>/dev/null
      sync
    
    if you do the two writes + sync in a loop, you can force btrfs to spin
    an excessive amount on semi-successful clustered allocations, before
    ultimately failing and advancing to the stage where we force a chunk
    allocation. This results in 2G of data allocated per iteration, despite
    only using ~20M of data. By using a small size classed extent, the inner
    loop takes longer and we can spin for longer.
    
    The simplest, shortest term fix to unbreak this is to make the clustered
    allocator size_class aware in the dumbest way, where it fails on size
    class mismatch. This may hinder the operation of the clustered
    allocator, but better hindered than completely broken and terribly
    overallocating.
    
    Further re-design improvements are also in the works.

类型	指派人员	状态
审查	hsiangkao josephhz JeffleXu	已完成 (0/0人)
测试	小龙已测试通过	已完成 (1/1人)

GVPanolis/cloud-kernel

搜索帮助

GVP anolis/cloud-kernel