Skip to content
  • Josef Bacik's avatar
    Btrfs: async block group caching · 817d52f8
    Josef Bacik authored
    
    
    This patch moves the caching of the block group off to a kthread in order to
    allow people to allocate sooner.  Instead of blocking up behind the caching
    mutex, we instead kick of the caching kthread, and then attempt to make an
    allocation.  If we cannot, we wait on the block groups caching waitqueue, which
    the caching kthread will wake the waiting threads up everytime it finds 2 meg
    worth of space, and then again when its finished caching.  This is how I tested
    the speedup from this
    
    mkfs the disk
    mount the disk
    fill the disk up with fs_mark
    unmount the disk
    mount the disk
    time touch /mnt/foo
    
    Without my changes this took 11 seconds on my box, with these changes it now
    takes 1 second.
    
    Another change thats been put in place is we lock the super mirror's in the
    pinned extent map in order to keep us from adding that stuff as free space when
    caching the block group.  This doesn't really change anything else as far as the
    pinned extent map is concerned, since for actual pinned extents we use
    EXTENT_DIRTY, but it does mean that when we unmount we have to go in and unlock
    those extents to keep from leaking memory.
    
    I've also added a check where when we are reading block groups from disk, if the
    amount of space used == the size of the block group, we go ahead and mark the
    block group as cached.  This drastically reduces the amount of time it takes to
    cache the block groups.  Using the same test as above, except doing a dd to a
    file and then unmounting, it used to take 33 seconds to umount, now it takes 3
    seconds.
    
    This version uses the commit_root in the caching kthread, and then keeps track
    of how many async caching threads are running at any given time so if one of the
    async threads is still running as we cross transactions we can wait until its
    finished before handling the pinned extents.  Thank you,
    
    Signed-off-by: default avatarJosef Bacik <jbacik@redhat.com>
    Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
    817d52f8