This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: prototype ext3 tapset
- From: "Nguyen, Thang P" <thang dot p dot nguyen at intel dot com>
- To: <jrs at us dot ibm dot com>, "Tom Zanussi" <zanussi at us dot ibm dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Fri, 28 Jul 2006 13:32:37 -0700
- Subject: RE: prototype ext3 tapset
Hi Jose,
I will work with Tom to review io.stp and ioblock.stp and see if we can
merge them.
Thanks,
Thang
-----Original Message-----
From: systemtap-owner@sourceware.org
[mailto:systemtap-owner@sourceware.org] On Behalf Of Jose R. Santos
Sent: Friday, July 28, 2006 1:28 PM
To: Tom Zanussi
Cc: systemtap@sources.redhat.com
Subject: Re: prototype ext3 tapset
Hi Tom,
It looks good overall. It seems that io.stp is equivalent in purpose to
ioblock.stp (which is already in SystemTap) and they should be merge
into a single tapset. We will look into adding trace hooks into LKET
using this tapset as a preview of what to expect.
As far as the scripts go. I like the idea of the iotop.stp but its
current output is of little use to me. I would like to see something
like this:
Process Total Bytes (Read/Write)
-------------- --------------------------
kjournald[779] 3522560 (0/3522560)
/dev/sda 1761280 (0/1761280) svctm 2.2
/dev/sdb 1761280 (0/1761280) svctm 5.3
Were we split the total ios between all the disk being written to as
well as getting the average service time of the IO that a certain
process is doing to each disk. I've been involved in several situations
were getting this type of information would have been of great help in
analyzing a problem. I had plans to create an LKET post-processing
program for analyzing this sort of data, but this is a common enough
problem that having separate systemtap script would also be a good
alternative when a full system trace is not required.
-JRS