linux-btrace.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch 0/2] blkparse extensions for PC requests
@ 2008-01-07  7:50 Christof Schmitt
  2008-01-11  9:10 ` Jens Axboe
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Christof Schmitt @ 2008-01-07  7:50 UTC (permalink / raw)
  To: linux-btrace

As a follow-up to the blktrace extension for SCSI generic device files, here
are two patches that extend the tracing of PC requests in blkparse. When
tracing I/O to SCSI tape drives, the I/O trace only contains PC requests. These
extensions allow to get some more data from these traces.

-- 
Christof Schmitt

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch 0/2] blkparse extensions for PC requests
  2008-01-07  7:50 [patch 0/2] blkparse extensions for PC requests Christof Schmitt
@ 2008-01-11  9:10 ` Jens Axboe
  2008-01-14  6:38 ` Christof Schmitt
  2008-01-14  7:53 ` Jens Axboe
  2 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2008-01-11  9:10 UTC (permalink / raw)
  To: linux-btrace

On Mon, Jan 07 2008, Christof Schmitt wrote:
> As a follow-up to the blktrace extension for SCSI generic device
> files, here are two patches that extend the tracing of PC requests in
> blkparse. When tracing I/O to SCSI tape drives, the I/O trace only
> contains PC requests. These extensions allow to get some more data
> from these traces.

Patches look fine, however should it just not default do this
accounting? But only print the status fields, if we actually saw a PC
request.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch 0/2] blkparse extensions for PC requests
  2008-01-07  7:50 [patch 0/2] blkparse extensions for PC requests Christof Schmitt
  2008-01-11  9:10 ` Jens Axboe
@ 2008-01-14  6:38 ` Christof Schmitt
  2008-01-14  7:53 ` Jens Axboe
  2 siblings, 0 replies; 4+ messages in thread
From: Christof Schmitt @ 2008-01-14  6:38 UTC (permalink / raw)
  To: linux-btrace

On Fri, Jan 11, 2008 at 10:10:35AM +0100, Jens Axboe wrote:
> Patches look fine, however should it just not default do this
> accounting? But only print the status fields, if we actually saw a PC
> request.

My intent was to not change the data shown in the current summary
output. But you are right, it makes more sense to simply output the PC
summary when a PC request has been seen. I will post an updated patch
that does this without the --pc flag.

Christof Schmitt

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch 0/2] blkparse extensions for PC requests
  2008-01-07  7:50 [patch 0/2] blkparse extensions for PC requests Christof Schmitt
  2008-01-11  9:10 ` Jens Axboe
  2008-01-14  6:38 ` Christof Schmitt
@ 2008-01-14  7:53 ` Jens Axboe
  2 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2008-01-14  7:53 UTC (permalink / raw)
  To: linux-btrace

On Mon, Jan 14 2008, Christof Schmitt wrote:
> On Fri, Jan 11, 2008 at 10:10:35AM +0100, Jens Axboe wrote:
> > Patches look fine, however should it just not default do this
> > accounting? But only print the status fields, if we actually saw a PC
> > request.
> 
> My intent was to not change the data shown in the current summary
> output. But you are right, it makes more sense to simply output the PC
> summary when a PC request has been seen. I will post an updated patch
> that does this without the --pc flag.

Yep I think so. If you send a patch that does that, I'll apply it.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-01-14  7:53 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-01-07  7:50 [patch 0/2] blkparse extensions for PC requests Christof Schmitt
2008-01-11  9:10 ` Jens Axboe
2008-01-14  6:38 ` Christof Schmitt
2008-01-14  7:53 ` Jens Axboe

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).