From: "Theodore Ts'o" <tytso@mit.edu>
To: Chunguang Xu <brookxu.cn@gmail.com>
Cc: adilger.kernel@dilger.ca, jack@suse.com,
harshadshirwadkar@gmail.com, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/4] make jbd2 debug switch per device
Date: Mon, 25 Jan 2021 16:50:50 -0500 [thread overview]
Message-ID: <YA89Ov+yuX6BHJpS@mit.edu> (raw)
In-Reply-To: <cover.1611402263.git.brookxu@tencent.com>
On Sat, Jan 23, 2021 at 08:00:42PM +0800, Chunguang Xu wrote:
> On a multi-disk machine, because jbd2 debugging switch is global, this
> confuses the logs of multiple disks. It is not easy to distinguish the
> logs of each disk and the amount of generated logs is very large. Maybe
> a separate debugging switch for each disk would be better, so that we
> can easily distinguish the logs of a certain disk.
>
> We can enable jbd2 debugging of a device in the following ways:
> echo X > /proc/fs/jbd2/sdX/jbd2_debug
>
> But there is a small disadvantage here. Because the debugging switch is
> placed in the journal_t object, the log before the object is initialized
> will be lost. However, usually this will not have much impact on
> debugging.
The jbd debugging infrastructure dates back to the very beginnings of
ext3, when Stephen Tweedie added them while he was first implementing
the jbd layer. So this dates back to a time before we had other
schemes like dynamic debug or tracepoints or eBPF.
I wonder if instead of trying to enhance our own bespoke debugging
system, instead we set up something like tracepoints where they would
be useful. I'm not proposing that we try to replace all jbd_debug()
statements with tracepoints but I think it would be useful to look at
what sort of information would actually be *useful* on a production
server, and add those tracepoints to the jbd2 layer. What I like
about tracepoints is you can enable them on a much more fine-grained
fashion; information is sent to userspace in a much more efficient
manner than printk; you can filter tracepoint events in the kernel,
before sending them to userspace; and if you want more sophisticated
filtering or aggregation, you can use eBPF.
What was the original use case which inspired this? Were you indeed
trying to debug some kind of problem on a production system? (Why did
you have multiple disks active at the same time?) Was there a
specific problem you were trying to debug? What debug level were you
using? Which jbd_debug statements were most useful to you? Which
just got in the way (but which had to be enabled given the log level
you needed to get the debug messages that you needed)?
- Ted
next prev parent reply other threads:[~2021-01-25 21:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-23 12:00 [RFC PATCH v2 0/4] make jbd2 debug switch per device Chunguang Xu
2021-01-23 12:00 ` [RFC PATCH v2 1/4] jbd2: make jdb2_debug module parameter " Chunguang Xu
2021-01-25 17:15 ` harshad shirwadkar
2021-01-26 0:21 ` brookxu
2021-01-23 12:00 ` [RFC PATCH v2 2/4] jbd2: introduce some new log interfaces Chunguang Xu
2021-01-25 14:54 ` Jan Kara
2021-01-25 15:53 ` brookxu
2021-01-23 12:00 ` [RFC PATCH v2 3/4] jbd2: replace jbd_debug with the new log interface Chunguang Xu
2021-01-23 12:00 ` [RFC PATCH v2 4/4] ext4: " Chunguang Xu
2021-01-25 21:50 ` Theodore Ts'o [this message]
2021-01-26 0:50 ` [RFC PATCH v2 0/4] make jbd2 debug switch per device brookxu
2021-01-27 16:21 ` Theodore Ts'o
2021-01-28 11:39 ` brookxu
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=YA89Ov+yuX6BHJpS@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=brookxu.cn@gmail.com \
--cc=harshadshirwadkar@gmail.com \
--cc=jack@suse.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).