From: "Theodore Ts'o" <tytso@mit.edu>
To: brookxu <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: Wed, 27 Jan 2021 11:21:16 -0500 [thread overview]
Message-ID: <YBGS/FJ8boyxyaPn@mit.edu> (raw)
In-Reply-To: <c2bfc960-d86c-b20a-e3eb-7995200a5dd8@gmail.com>
On Tue, Jan 26, 2021 at 08:50:02AM +0800, brookxu wrote:
>
> trace point, eBPF and other hook technologies are better for production
> environments. But for pure debugging work, adding hook points feels a bit
> heavy. However, your suggestion is very valuable, thank you very much.
What feels heavy? The act of adding a new jbd_debug() statement to
the sources, versus adding a new tracepoint? Or how to enable a set
of tracepoints versus setting a jbd_debug level (either globally, or
per mount point)? Or something else?
If it's the latter (which is what I think it is), how often are you
needing to add a new jbd_debug() statement *and* needing to run in a
test environment where you have multiple disks? How often is it
useful to have multiple disks when doing your debugging?
I'm trying to understand why this has been useful to you, since that
generally doesn't match with my development, testing, or debugging
experience. In general I try to test with one file system at a time,
since I'm trying to find something reproducible. Do you have cases
where you need multiple file systems in your test environment in order
to do your testing? Why is that? Is it because you're trying to use
your production server code as your test reproducers? And if so, I
would have thought adding the jbd_debug() statements and sending lots
of console print messages would distort the timing enough to make it
hard to reproduce a problem in found in your production environment.
It sounds like you have a very different set of test practices than
what I'm used to, and I'm trying to understand it better.
Cheers,
- Ted
next prev parent reply other threads:[~2021-01-27 16:22 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 ` [RFC PATCH v2 0/4] make jbd2 debug switch per device Theodore Ts'o
2021-01-26 0:50 ` brookxu
2021-01-27 16:21 ` Theodore Ts'o [this message]
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=YBGS/FJ8boyxyaPn@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).