This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: prototype ext3 tapset
- From: Tom Zanussi <zanussi at us dot ibm dot com>
- To: jrs at us dot ibm dot com
- Cc: Tom Zanussi <zanussi at us dot ibm dot com>, systemtap at sources dot redhat dot com
- Date: Fri, 28 Jul 2006 16:51:12 -0500
- Subject: Re: prototype ext3 tapset
- References: <17609.10066.744205.176468@tut.ibm.com> <44CA7362.7080805@us.ibm.com>
Jose R. Santos writes:
> 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.
Yeah, I didn't notice ioblock.stp right away, so there's probably
some needless duplication there.
>
> 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.
>
>
Thanks, just the kind of suggestion I was looking for!
Tom