Re: question about transaction-abort-related commits

[Josef Bacik <jbacik@fusionio.com>]

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.btrfs@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