From: Peter J Braam <Peter.Braam@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] I/O trace tool
Date: Mon, 07 Jan 2008 10:24:52 +0100 [thread overview]
Message-ID: <4781EFE4.6090104@sun.com> (raw)
In-Reply-To: <475C191B.7030204@sun.com>
Hi Tom -
Tom.Wang wrote:
> Hello,
>
> Here is an idea for lustre I/O trace tool.
>
> We can provide 1 new lfs utility, for example lfs trace.
>
> So in the I/O trace job, we could
>
> 1) lfs trace job_id start (Enable all the trace dump on OSS and MDS
> for this job, here the trace means the information under /proc or some
> debug log, but also may add
> some other information. maybe in llog format)
> 2) Run the application.
> 3) lfs trace job_id stop trace_log. (Disable the trace dump on the
> servers, and get the trace log from these servers).
>
> But here is a problem, since this tool will be used by normal
> end-user, so the lfs should only enable the trace
> for the request of this job. But current, server can not identify the
> job id at all. And also maintaining the job_id for the job
> may also bring some troubles.
The logging system allows to follow the xid of requests executed on
clients to server threads. I am not sure if this is fully implemented.
It is important that this problem is resolved, and I think you can do
it. Of course requests sometimes initiate from cache flushes etc and in
this case finding the source is maybe not so easy.
- Peter -
> An alternative way is to identify the request by uid and gid on the
> server, then only requests from
> this user will be traced, but then the end user can only run that
> trace job at that time.
> Any ideas?
>
> Thanks
> WangDi
>
>
>
>
>
>
>
>
>
>
>
>
parent reply other threads:[~2008-01-07 9:24 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <475C191B.7030204@sun.com>]
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=4781EFE4.6090104@sun.com \
--to=peter.braam@sun.com \
--cc=lustre-devel@lists.lustre.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.