On 12.04.2017 19:10, Christoph Hellwig wrote: > Hi Nikolay, > > I guess the culprit is that truncate can free up to two extents in > the same transaction and thus try to lock two different AGs without > requiring them to be in increasing order. > > Does the one liner below fix the problem for you? So after 200 runs of generic/299 I didn't hit the deadlock whereas before it would hit in the first 30 or so. FWIW : Tested-by: Nikolay Borisov <nborisov@xxxxxxxx> On a different note - do you think that reducing the unmapped extents from 2 to 1 would introduce any performance degradation during truncation? 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. Regards, Nikolay -- 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
