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. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
