Re: [PATCH 8/7] blktrace: support discard requests

[Jens Axboe <jens.axboe@oracle.com>]

On Sun, Aug 10 2008, David Woodhouse wrote:
> While doing this, I note blktrace doesn't handle partial completion
> particularly well. Since our FTL implementations currently don't care
> about merged requests and just call end_request(), we see this (note the
> sector counts in the completion events, which _should_ all be '+ 16')...
>  44,0    0      500  1010.573373912  2759  D   D 1843 + 96 [ftld]
>  44,0    0      501  1010.581654276  2759  C   D 1843 + 96 [0]
>  44,0    0      502  1010.589936163  2759  C   D 1859 + 80 [0]
>  44,0    0      503  1010.598221556  2759  C   D 1875 + 64 [0]
>  44,0    0      504  1010.606505959  2759  C   D 1891 + 48 [0]
>  44,0    0      505  1010.614787227  2759  C   D 1907 + 32 [0]
>  44,0    0      506  1010.623061067  2759  C   D 1923 + 16 [0]
> 
> Do we want to pass nr_bytes into blk_add_trace_rq() from
> __end_that_request_first()?

Yep, that does indeed look like a bug!

> It's also a bit suboptimal that 'blktrace /dev/ftla -o- | blkparse -i-'
> stalls when it hits the first message packet, and then starts storing
> requests to be sorted, never printing anything more until you hit ^C.
> 
> I just removed the '&& bit->action != BLK_TN_MESSAGE' from line 2197 of
> blkparse.c but that means the output isn't in the right order. Some kind
> of partial sort might be nice, if we can do it -- wait for a pause or
> some kind of marker in the stream, then sort and print what we have
> batched, then continue waiting for new events... 

I'll take patches, it's a pretty tricky area... Live tracing really
isn't that well supported, the only way to guarantee "perfect" traces is
to do post-processing.

-- 
Jens Axboe