Hi, Steffen and Kazu
Sorry, I missed this information.
On Tue, Jan 4, 2022 at 9:10 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx> 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 Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility
