• Filipe Manana's avatar
    btrfs: ensure relocation never runs while we have send operations running · 1cea5cf0
    Filipe Manana authored
    Relocation and send do not play well together because while send is
    running a block group can be relocated, a transaction committed and
    the respective disk extents get re-allocated and written to or discarded
    while send is about to do something with the extents.
    
    This was explained in commit 9e967495 ("Btrfs: prevent send failures
    and crashes due to concurrent relocation"), which prevented balance and
    send from running in parallel but it did not address one remaining case
    where chunk relocation can happen: shrinking a device (and device deletion
    which shrinks a device's size to 0 before deleting the device).
    
    We also have now one more case where relocation is triggered: on zoned
    filesystems partially used block groups get relocated by a background
    thread, introduced in commit 18bb8bbf ("btrfs: zoned: automatically
    reclaim zones").
    
    So make sure that instead of preventing balance from running when there
    are ongoing send operations, we prevent relocation from happening.
    This uses the infrastructure recently added by a patch that has the
    subject: "btrfs: add cancellable chunk relocation support".
    
    Also it adds a spinlock used exclusively for the exclusivity between
    send and relocation, as before fs_info->balance_mutex was used, which
    would make an attempt to run send to block waiting for balance to
    finish, which can take a lot of time on large filesystems.
    Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
    Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
    Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
    1cea5cf0
volumes.c 214 KB