Re: Deadlock between block allocation and block truncation

[Christoph Hellwig <hch@infradead.org>]

On Thu, Apr 13, 2017 at 04:52:03PM +0300, Nikolay Borisov wrote:
> On a different note - do you think that reducing the unmapped extents
> from 2 to 1 would introduce any performance degradation during
> truncation?

There will be some.  But now that we have the CIL it will just
additional in-kernel overhead instead of overhead in the on-disk
log.

> Looking around the code this define is only used when doing
> truncation, so perhaps a better thing to do would be to turn this
> xfs_bunmapi arg to a boolean which signal whether we are doing
> truncation or not. And if it is set to true have xfs_bunmapi unmap all
> possible extents from only a single AG? I'm going to sift through the
> git history to figure out where this requirement of maximum 2 extent
> came to truncate, came.

We have the problem with all transactions that could lock multiple AGF
headers, so that's not going to cut it.

I think we could do multiple transactions IFF in the same AG.  I'll
need to check if that's worth it.  And on top of that I have started
entirely reworking what is currently xfs_bunmapi, but that will have
to wait until after a fix for your issue.