[dm-devel] [PATCH v2 05/13] dm-mpath: Make it easier to analyze requeuing behavior

Bart Van Assche Bart.VanAssche at sandisk.com
Thu Apr 27 19:57:27 UTC 2017


On Thu, 2017-04-27 at 15:29 -0400, Mike Snitzer wrote:
> Documentation/process/coding-style.rst says:
> "Coming up with good debugging messages can be quite a challenge; and once
> you have them, they can be a huge help for remote troubleshooting.  However
> debug message printing is handled differently than printing other non-debug
> messages.  While the other pr_XXX() functions print unconditionally,
> pr_debug() does not; it is compiled out by default, unless either DEBUG is
> defined or CONFIG_DYNAMIC_DEBUG is set."
> 
> So I assume you're leveraging DYNAMIC_DEBUG.
> 
> Anyway, I'm not liking the idea of making this debugging part of the
> mpath code.  But if there is a convincing argument for it please
> elaborate.
> 
> Are you finding that things are going wrong on production systems and
> enabling pr_debug() in these paths would have, or has, saved you?

Hello Mike,

If the dm-mpath driver is busy with requeuing requests in a loop today there
is no way to figure out why that continuous requeuing happens. The pr_debug()
statements introduced by this patch provide an easy way to figure out on
development systems why the requeuing happens. Please note that there is no
guarantee on production systems that CONFIG_DYNAMIC_DEBUG=y.

Bart.




More information about the dm-devel mailing list