On Fri, Feb 12 2016 at 11:04am -0500, Hannes Reinecke <hare@xxxxxxx> wrote: > On 02/12/2016 04:26 PM, Mike Snitzer wrote: > >On Fri, Feb 12 2016 at 10:18am -0500, > >Hannes Reinecke <hare@xxxxxxx> wrote: > >>> > >>Good news is that I've managed to hit the roof for my array with the > >>devel2 version of those patches. (And a _heavily_ patched-up lpfc > >>driver :-) > >>So from that perspective everything's fine now; we've reached the > >>hardware limit for my setup. > >>Which in itself is quite impressive; beating Intel P3700 with 16FC > >>is not bad methinks :-) > >> > >>So thanks for all your work here. > > > >Ah, that's really good news! But devel2 is definitely _not_ destined > >for upstream. 'devel3' is much closer to "ready". But your testing and > >review would really push it forward. > > > >Please see/test: > >http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/log/?h=devel3 > > > >Also, please read this header: > >http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=devel3&id=65a01b76502dd68e8ca298ee6614c0151b677f4a > > > >Even with devel2 I hacked it such that repeat_count > 1 is effectively > >broken. I'm now _seriously_ considering deprecating repeat_count > >completely (adding a DMWARN that will inform the user. e.g.: > >"repeat_count > 1 is no longer supported"). I see no point going to > >great lengths to maintain a dm-mpath feature that was only a hack for > >when dm-mpath was bio-based. What do you think? > > Drop it, and make setting of which a no-op. > Never liked it anyway, and these decisions should really be > delegated to the path selector. Sure, but my point is DM-mpath will no longer be able to provide the ability to properly handle repeat_count > 1 (because updating the ->current_pgpath crushes the write-side of the RCU). As such I've rebased 'devel3' to impose repeat_count = 1 (both in dm-mpath.c and the defaults in each path selector). -- 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
