• Josef Bacik's avatar
    Btrfs: find ideal block group for caching · ccf0e725
    Josef Bacik authored
    This patch changes a few things.  Hopefully the comments are helpfull, but
    I'll try and be as verbose here.
    
    Problem:
    
    My fedora box was taking 1 minute and 21 seconds to boot with btrfs as root.
    Part of this problem was we pick the first block group we can find and start
    caching it, even if it may not have enough free space.  The other problem is
    we only search for cached block groups the first time around, which we won't
    find any cached block groups because this is a newly mounted fs, so we end up
    caching several block groups during bootup, which with alot of fragmentation
    takes around 30-45 seconds to complete, which bogs down the system.  So
    
    Solution:
    
    1) Don't cache block groups willy-nilly at first.  Instead try and figure out
    which block group has the most free, and therefore will take the least amount
    of time to cache.
    
    2) Don't be so picky about cached block groups.  The other problem is once
    we've filled up a cluster, if the block group isn't finished caching the next
    time we try and do the allocation we'll completely ignore the cluster and
    start searching from the beginning of the space, which makes us cache more
    block groups, which slows us down even more.  So instead of skipping block
    groups that are not finished caching when we have a hint, only skip the block
    group if it hasn't started caching yet.
    
    There is one other tweak in here.  Before if we allocated a chunk and still
    couldn't find new space, we'd end up switching the space info to force another
    chunk allocation.  This could make us end up with way too many chunks, so keep
    track of this particular case.
    
    With this patch and my previous cluster fixes my fedora box now boots in 43
    seconds, and according to the bootchart is not held up by our block group
    caching at all.
    Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
    Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
    ccf0e725
extent-tree.c 200 KB