• Josef Bacik's avatar
    btrfs: handle space_info::total_bytes_pinned inside the delayed ref itself · 2187374f
    Josef Bacik authored
    Currently we pass things around to figure out if we maybe freeing data
    based on the state of the delayed refs head.  This makes the accounting
    sort of confusing and hard to follow, as it's distinctly separate from
    the delayed ref heads stuff, but also depends on it entirely.
    
    Fix this by explicitly adjusting the space_info->total_bytes_pinned in
    the delayed refs code.  We now have two places where we modify this
    counter, once where we create the delayed and destroy the delayed refs,
    and once when we pin and unpin the extents.  This means there is a
    slight overlap between delayed refs and the pin/unpin mechanisms, but
    this is simply used by the ENOSPC infrastructure to determine if we need
    to commit the transaction, so there's no adverse affect from this, we
    might simply commit thinking it will give us enough space when it might
    not.
    
    CC: stable@vger.kernel.org # 5.10
    Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
    Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
    Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
    2187374f
delayed-ref.h 11 KB