On Sun, Jun 30, 2013 at 11:29:14AM +0300, Alex Lyakas wrote: > Hi Josef, > > On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas > <alex.bt...@zadarastorage.com> wrote: > > Hi Josef, > > Can you please help me with another question. > > > > I am looking at your patch: > > Btrfs: fix chunk allocation error handling > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0448748849ef7c593be40e2c1404f7974bd3aac6 > > > > Here you changed the order of btrfs_make_block_group() vs > > btrfs_alloc_dev_extent(), because we could have allocated from the > > in-memory block group, before we have inserted the dev extent into a > > tree. However, with this fix, I hit the deadlock[1] of > > btrfs_alloc_dev_extent() that also wants to allocate a chunk and > > recursively calls do_chunk_alloc, but then is stuck on chunk_mutex. > > > > Was this patch: > > Btrfs: don't re-enter when allocating a chunk > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6b305a89b1903d63652691ad5eb9f05aa0326b8 > > introduced to fix this deadlock? > > With these two patches ("Btrfs: fix chunk allocation error handling" > and "Btrfs: don't re-enter when allocating a chunk"), I am hitting > ENOSPC during metadata chunk allocation. > > Upon entry into "do_chunk_alloc", I have only one METADATA block-group > as follows: > total_bytes=8388608 > bytes_used=7938048 > bytes_pinned=446464 > bytes_reserved=4096 > bytes_readonly=0 > bytes_may_use=3362816 > > As we see bytes_used+bytes_pinned+bytes_reserved==total_bytes > > What happens next is that within __btrfs_alloc_chunk(): > - find_free_dev_extent() finds a free extent (metadata policy is SINGLE) > - btrfs_alloc_dev_extent() fails with ENOSPC > > (btrfs_make_block_group() is called after btrfs_alloc_dev_extent() > with these patches). > > What should be done in such situation, when there is not enough > METADATA to allocate a device extent item, but we still don't allow > allocating from the newly-created METADATA block group? >
So I had a third patch that you are likely missing that makes sure we try and allocate chunks sooner specifically for this case 96f1bb57771f71bf1d55d5031a1cf47908494330 and then Miao made it better I think with this 3c76cd84e0c0d3ceb094a1020f8c55c2417e18d3 Thanks, Josef -- 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
