On Fri, May 06, 2016 at 06:27:05PM +0200, Christoph Hellwig wrote: > On Fri, May 06, 2016 at 12:19:16PM -0400, Mike Snitzer wrote: > > (this is a direct result of completing the discard bio before all > > mappings, and associated sub-discards, have): > > The completion order really should not matter, we rely on it not > mattering for almost every usage of the bio_chain API. So there > is something else fishy going on here. What's your test case? > I'd like to dig a bit deeper into this. Completion order isn't important. The issue we have is there are two levels of fragmentation that we see with thinp. First a large discard (eg, mkfs) comes in. We then break this up into mapped regions. Then each region is quiesced individually. Once quiesced we then can discard the region, with the extra twist that we can't discard any areas that are shared between snapshots. The patches Mike posted switch to use your new bio_chain/blk_issue_thing (which I like btw) on the bottom level (ie, each region). So we need some form of ref counting to work out when all the mid level regions are complete and hence we can complete the original bio. It's not rocket science, and is generating far more discussion than is neccessary. If I can't piggy back on the bio's ref count, I'll create my own. - Joe -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
