• J
    Btrfs: make the chunk allocator completely tree lockless · 6df9a95e
    Josef Bacik 提交于
    When adjusting the enospc rules for relocation I ran into a deadlock because we
    were relocating the only system chunk and that forced us to try and allocate a
    new system chunk while holding locks in the chunk tree, which caused us to
    deadlock.  To fix this I've moved all of the dev extent addition and chunk
    addition out to the delayed chunk completion stuff.  We still keep the in-memory
    stuff which makes sure everything is consistent.
    
    One change I had to make was to search the commit root of the device tree to
    find a free dev extent, and hold onto any chunk em's that we allocated in that
    transaction so we do not allocate the same dev extent twice.  This has the side
    effect of fixing a bug with balance that has been there ever since balance
    existed.  Basically you can free a block group and it's dev extent and then
    immediately allocate that dev extent for a new block group and write stuff to
    that dev extent, all within the same transaction.  So if you happen to crash
    during a balance you could come back to a completely broken file system.  This
    patch should keep these sort of things from happening in the future since we
    won't be able to allocate free'd dev extents until after the transaction
    commits.  This has passed all of the xfstests and my super annoying stress test
    followed by a balance.  Thanks,
    Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
    6df9a95e
volumes.c 153.7 KB