linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: "Aurélien Aptel" <aaptel@suse.com>
Cc: Ronnie Sahlberg <lsahlber@redhat.com>,
	linux-cifs <linux-cifs@vger.kernel.org>,
	Steve French <smfrench@gmail.com>
Subject: Re: [PATCH] cifs: add new debugging macro cifs_server_dbg
Date: Wed, 28 Aug 2019 20:13:46 +1000	[thread overview]
Message-ID: <CAN05THRc24L1MBbOHfT6r4WJEiucjkrr3cE7d7uo65M1b+dNsA@mail.gmail.com> (raw)
In-Reply-To: <87o909li6g.fsf@suse.com>

On Wed, Aug 28, 2019 at 8:05 PM Aurélien Aptel <aaptel@suse.com> wrote:
>
> Ronnie Sahlberg <lsahlber@redhat.com> writes:
> > which can be used from contexts where we have a TCP_Server_Info *server.
> > This new macro will prepend the debugging string with "Server:<servername> "
> > which will help when debugging issues on hosts with many cifs connections
> > to several different servers.
> >
> > Convert a bunch of callsites in connect.c from cifs_dbg to instead use
> > cifs_server_dbg.
>
> This looks like a poorman's ftrace. I'm not sure about it I think it
> would make more sense to add those (or convert) as ftrace tracepoints as
> it supports filtering built-in.

In a sense they are but the usecase is different.
Ftrace is way superior if you can handily reproduce an issue in a lab and test.
This is to make the dmesg output more meaningful for production scenarios where
running a long ftrace is not an option.


If there is an issue that takes days/weeks/.. to reproduce on a
production system
you can't run ftrace for that long.

This is for triage when you have rare events that can not (easily) be
reproduced on production
systems and when after the fact you only have dmesg to further aid in
how to proceed to triage an issue.


>
> --
> Aurélien Aptel / SUSE Labs Samba Team
> GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)

  reply	other threads:[~2019-08-28 10:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28  3:17 [PATCH] cifs: add new debugging macro cifs_server_dbg Ronnie Sahlberg
2019-08-28 10:04 ` Aurélien Aptel
2019-08-28 10:13   ` ronnie sahlberg [this message]
2019-08-28  7:15 [PATCH 0/1] add new debugging macro Ronnie Sahlberg
2019-08-28  7:15 ` [PATCH] cifs: add new debugging macro cifs_server_dbg Ronnie Sahlberg
2019-08-30  1:47   ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN05THRc24L1MBbOHfT6r4WJEiucjkrr3cE7d7uo65M1b+dNsA@mail.gmail.com \
    --to=ronniesahlberg@gmail.com \
    --cc=aaptel@suse.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=lsahlber@redhat.com \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).