On Sunday 13 Dec 2015 12:18:55 Alex Lyakas wrote: > [Resending in plain text, apologies.] > > Hi Chandan, Josef, Chris, > > I am not sure I understand the fix to the problem. > > It may happen that when updating the device tree, we need to allocate a new > chunk via do_chunk_alloc (while we are holding the device tree root node > locked). This is a legitimate thing for find_free_extent() to do. And > do_chunk_alloc() call may lead to call to > btrfs_create_pending_block_groups(), which will try to update the device > tree. This may happen due to direct call to > btrfs_create_pending_block_groups() that exists in do_chunk_alloc(), or > perhaps by __btrfs_end_transaction() that find_free_extent() does after it > completed chunk allocation (although in this case it will use the > transaction that already exists in current->journal_info). > So the deadlock still may happen?
Hello Alex, The "global block reservation" (see btrfs_fs_info->global_block_rsv) aims to solve this problem. I don't claim to have understood the behaviour of global_block_rsv completely. However, Global block reservation makes sure that we have enough free space reserved (see update_global_block_rsv()) for future operations on, - Extent tree - Checksum tree - Device tree - Tree root tree and - Quota tree. Tasks changing the device tree should get their space requirements satisfied from the global block reservation. Hence such changes to the device tree should not end up forcing find_free_extent() to allocate a new chunk. -- chandan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
