On 9/18/19 1:28 PM, Chaitanya Kulkarni wrote: > On 09/17/2019 07:32 PM, Jens Axboe wrote: >> Regular io stats get merging stats for read/write/trim. Why do we need >> something else for this? >> >> -- Jens Axboe > > Yes, but we don't have a mechanism through debug-fs to have such per > request type information which makes debugging much easier. > > One such a scenario where we want to add a new request type and > examine rq_merged not as a whole number, which is not covered by > the io stats (since it only covers read/write/trim). What is this new request type that supports merging? My point is that adding stats like this isn't free, it's a runtime cost. And if it's just for debugging, there better be a damn good reason for why we'd want to pay this cost the 99.999% of the time where nobody is looking at those counters. So why isn't the iostat stuff good enough? There's also the option of having blktrace tell you this information, it would not be hard to add a blktrace-stats type of tool that'll just give you the last second of stats so you wouldn't have to store the data, for example. What I'm asking for is justification for adding these stats, so far I don't see any outside of perhaps convenience, it's easier to just add them to blk-mq and retrieve them through debugfs. -- Jens Axboe
