• Josef Bacik's avatar
    Btrfs: free space accounting redo · 0f9dd46c
    Josef Bacik authored
    1) replace the per fs_info extent_io_tree that tracked free space with two
    rb-trees per block group to track free space areas via offset and size.  The
    reason to do this is because most allocations come with a hint byte where to
    start, so we can usually find a chunk of free space at that hint byte to satisfy
    the allocation and get good space packing.  If we cannot find free space at or
    after the given offset we fall back on looking for a chunk of the given size as
    close to that given offset as possible.  When we fall back on the size search we
    also try to find a slot as close to the size we want as possible, to avoid
    breaking small chunks off of huge areas if possible.
    
    2) remove the extent_io_tree that tracked the block group cache from fs_info and
    replaced it with an rb-tree thats tracks block group cache via offset.  also
    added a per space_info list that tracks the block group cache for the particular
    space so we can lookup related block groups easily.
    
    3) cleaned up the allocation code to make it a little easier to read and a
    little less complicated.  Basically there are 3 steps, first look from our
    provided hint.  If we couldn't find from that given hint, start back at our
    original search start and look for space from there.  If that fails try to
    allocate space if we can and start looking again.  If not we're screwed and need
    to start over again.
    
    4) small fixes.  there were some issues in volumes.c where we wouldn't allocate
    the rest of the disk.  fixed cow_file_range to actually pass the alloc_hint,
    which has helped a good bit in making the fs_mark test I run have semi-normal
    results as we run out of space.  Generally with data allocations we don't track
    where we last allocated from, so everytime we did a data allocation we'd search
    through every block group that we have looking for free space.  Now searching a
    block group with no free space isn't terribly time consuming, it was causing a
    slight degradation as we got more data block groups.  The alloc_hint has fixed
    this slight degredation and made things semi-normal.
    
    There is still one nagging problem I'm working on where we will get ENOSPC when
    there is definitely plenty of space.  This only happens with metadata
    allocations, and only when we are almost full.  So you generally hit the 85%
    mark first, but sometimes you'll hit the BUG before you hit the 85% wall.  I'm
    still tracking it down, but until then this seems to be pretty stable and make a
    significant performance gain.
    Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
    0f9dd46c
volumes.c 63.3 KB