Hi, Steffen and Kazu Sorry, I missed this information. On Tue, Jan 4, 2022 at 9:10 AM HAGIO KAZUHITO(萩尾 一仁) <[email protected]> wrote:
> -----Original Message----- > > Admittedly, I haven't looked into the details, but those simple numbers > for > > pending IO have been very valuable for me, when analyzing dumps with > > dm-multipath over (FC-attached) SCSI disks. Aren't those pending IO > numbers > > available elsewhere in the kernel? Maybe not in debugfs anymore, but I > suppose > > the (mq) block layer does keep track of them? > > AFAIK, unfortunately there is no simple counter, crash needs to parse > sbitmap > structures to count them. (please let us know if there is a simpler > solution.) > Currently Sergey has worked on adding sbitmap function [1], and we plan to > make > use of it after merging the patch. It may take some time, so Lianbo's > patch is > a temporary workaround for the error. > In addition, I would like to add that the counter for the ctx->rq_completed/ctx->rq_dispatched(for 'dev -d') may become inaccurate due to racing per-cpu values in the kernel. I'm considering whether crash should print a warning or "not supported" for "dev -d", which can avoid misleading users. So far we have encountered two similar cases. What's your opinion?Kazu. BTW: Also added IIya to cc list. Thanks. Lianbo Maybe it was better to write the status on the commit log.. > > [1] > https://listman.redhat.com/archives/crash-utility/2021-December/msg00062.html > > Thanks, > Kazu > >
-- Crash-utility mailing list [email protected] https://listman.redhat.com/mailman/listinfo/crash-utility
