You said that btt doesn't differentiate between read and write
requests. If you use the -p option to see individual requests, I have
a patch that fixes that. I submitted it a while ago to the mailing
list, but it was ignored. If you're looking for aggregate statistics,
though, you'd have to compute them yourself.
The time stamps are since you started blktrace, so if there is a delay
between starting blktrace and starting your workload, the timestamps
will be larger.
As for your other concerns, someone else will have to address them.
I'm just another blktrace user, not a developer.
On Wed, Jan 8, 2014 at 3:15 AM, Abhishek Dnyate
<abhishek@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> Allow me to introduce myself- my name is Abhishek Dnyate and I work for Cumulus Systems.
> As a background we are using blktrace utility to add a Linux component to our high level performance analysis and charge back system called MARS.
> While developing this component, we came across btt utility, which would allow us to process the data collected by blktrace, and the reports generated by btt looks almost exactly what we want.
> But while using btt, we faced few glitches which might defeat the very purpose of using it.
>
> (We are referring to a pdf “btt User Guide” written by Alan D. Brunelle (Alan.Brunelle@xxxxxx), dated 12 February 2008.)
>
> Any help is greatly appreciated.
>
> ➢ Firstly, we want to know is btt supported as of today?
>
> ➢ We want btt to parse only a subset of blktrace file. btt has –t and –T option to specify the start and end time, which would allow it, but the document says:
> 11.17 --time-start/-t and --time-end/T
> This btt capability is still under construction, results are not always consistent at this point in time.
> btt version specified in the document is 2.00 and the current version we are using is 2.07. We are not sure that this issue still persists. And if it has been fixed, in which version of btt is it fixed ?
>
> ➢ As far as we understand, btt does not differentiate between read and write requests i.e. to say btt output files does not show the type of request. We kind of lose this information, collected by blktrace.
>
> ➢ As per the btt user guide (which we are referring to), it says the timestamp dumped in files is a relative offset since the start time of the trace (ref pg no 20, last para)
>
> But in actual we are getting timestamp values that are very high from what is expected.
> Is it the system uptime?
> Assuming it is system uptime, we also noticed that this value looked incorrect for an old kernel version (2.6.18), but matched exactly with the system uptime for a relatively later kernel version (2.6.32).
> Is there any specific kernel version , this would require?
> Command used to execute btt : btt -i sda.blktrace.0 -a -o <output_filename>
>
> Thanks in advance.
>
> Regards,
> Abhishek
>
diff --git a/btt/trace_complete.c b/btt/trace_complete.c
index 44732c5..ac10480 100644
--- a/btt/trace_complete.c
+++ b/btt/trace_complete.c
@@ -21,31 +21,32 @@
#include "globals.h"
static inline void __out(FILE *ofp, __u64 tm, enum iop_type type,
- __u64 sec, __u32 nsec, int indent)
+ __u64 sec, __u32 nsec, int write, int indent)
{
if (tm != (__u64)-1) {
if (indent)
fprintf(ofp, " ");
- fprintf(ofp, "%5d.%09lu %c %10llu+%-4u\n",
+ fprintf(ofp, "%5d.%09lu %c %10llu+%-4u %c\n",
(int)SECONDS(tm), (unsigned long)NANO_SECONDS(tm),
- type2c(type), (unsigned long long)sec, nsec);
+ type2c(type), (unsigned long long)sec, nsec, write?'W':'R');
}
}
static void display_io_track(FILE *ofp, struct io *iop)
{
+ int w = (iop->t.action & BLK_TC_ACT(BLK_TC_WRITE)) != 0;
fprintf(ofp, "%3d,%-3d: ", MAJOR(iop->t.device), MINOR(iop->t.device));
- __out(ofp, iop->t.time, IOP_Q, iop->t.sector, t_sec(&iop->t), 0);
+ __out(ofp, iop->t.time, IOP_Q, iop->t.sector, t_sec(&iop->t), w, 0);
if (iop->g_time != (__u64)-1)
- __out(ofp, iop->g_time, IOP_G, iop->t.sector, t_sec(&iop->t),1);
+ __out(ofp, iop->g_time, IOP_G, iop->t.sector, t_sec(&iop->t), w, 1);
if (iop->i_time != (__u64)-1)
- __out(ofp, iop->i_time, IOP_I, iop->t.sector, t_sec(&iop->t),1);
+ __out(ofp, iop->i_time, IOP_I, iop->t.sector, t_sec(&iop->t), w, 1);
if (iop->m_time != (__u64)-1)
- __out(ofp, iop->m_time, IOP_M, iop->t.sector, t_sec(&iop->t),1);
+ __out(ofp, iop->m_time, IOP_M, iop->t.sector, t_sec(&iop->t), w, 1);
- __out(ofp, iop->d_time, IOP_D, iop->d_sec, iop->d_nsec, 1);
- __out(ofp, iop->c_time, IOP_C, iop->c_sec, iop->c_nsec, 1);
+ __out(ofp, iop->d_time, IOP_D, iop->d_sec, iop->d_nsec, w, 1);
+ __out(ofp, iop->c_time, IOP_C, iop->c_sec, iop->c_nsec, w, 1);
fprintf(ofp, "\n");
}
