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

[Mike Snitzer <snitzer@redhat.com>]

On Thu, Apr 27 2017 at  1:11P -0400,
Bart Van Assche <bart.vanassche@sandisk.com> wrote:

> When debugging the dm-mpath driver it is important to know what
> decisions have been taken with regard to requeuing. Hence this
> patch that adds pr_debug() statements that report what decisions
> have been taken.
> 
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Reviewed-by: Hannes Reinecke <hare@suse.com>
> Cc: Christoph Hellwig <hch@lst.de>

I've not used pr_debug() before.. I generally sprinkle debugging when
I'm actively chasing an issue and then throw it away once I sort the
problem out.

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?