On 4/11/21 11:35 PM, Jinpu Wang wrote: > On Fri, Apr 9, 2021 at 11:03 PM Jens Axboe <axboe@xxxxxxxxx> wrote: >> >> On 4/9/21 10:03 AM, Md Haris Iqbal wrote: >>> Hi Jens, >>> >>> This version fixes the long lines in the code as per Christoph's comment. >> >> I'd really like to see some solid justification for the addition, >> though. I clicked the v1 link and it's got details on what you get out >> of it, but not really the 'why' of reasoning for the feature. I mean, >> you could feasibly have a blktrace based userspace solution. Just >> wondering if that has been tried, I know that's what we do at Facebook >> for example. >> > Hi Jens, > > Thanks for the reply. > For the use case of the additional stats, as a cloud provider, we > often need to handle report from the customers regarding > performance problem in a period of time in the past, so it's not > feasible for us to run blktrace, customer workload could change from > time to time, with the additional stats, we gather through all metrics > using Prometheus, we can navigate to the period of time interested, > to check if the performance matches the SLA, it also helps us to find > the user IO pattern, we can more easily reproduce. My suggestion isn't to run just blktrace all the time, rather collect the tracing info from there and store them away. Then you can go back in time and see what is going on. Hence my questioning on adding this new stat tracking, when it's already readily available to be consumed by a small daemon that can continually track it in userspace. -- Jens Axboe
