On 5/27/20 1:37 AM, Song Liu wrote:

On Mon, May 25, 2020 at 9:23 AM Michal Soltys [off-list ref] wrote:

quoted

On 5/19/20 1:55 AM, Song Liu wrote:

quoted

2. try use bcc/bpftrace to trace r5l_recovery_read_page(),
specifically, the 4th argument.
With bcc, it is something like:

      trace.py -M 100 'r5l_recovery_read_page() "%llx", arg4'

-M above limits the number of outputs to 100 lines. We may need to
increase the limit or
remove the constraint. If the system doesn't have bcc/bpftrace. You
can also try with
kprobe.

Looks like the kernel has processed about 1.2GB of journal (9b69bb8 -
98f65b8 sectors).
And the limit is min(1/4 disk size, 10GB).

I just checked the code, it should stop once it hits checksum
mismatch. Does it keep going
after half hour or so?

It keeps going so far (mdadm started few hours ago):

xs22:/home/msl☠ head -n 4 trace.out
TIME     PID     TID     COMM            FUNC             -
12:58:21 40739   40739   mdadm           r5l_recovery_read_page 98f65b8
12:58:21 40739   40739   mdadm           r5l_recovery_read_page 98f65c0
12:58:21 40739   40739   mdadm           r5l_recovery_read_page 98f65c8
xs22:/home/msl☠ tail -n 4 trace.out
15:34:50 40739   40739   mdadm           r5l_recovery_read_page bc04e88
15:34:50 40739   40739   mdadm           r5l_recovery_read_page bc04e90
15:34:50 40739   40739   mdadm           r5l_recovery_read_page bc04e98