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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
