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()? 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... -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation -- 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
