Re: btrfs-progs reports nonsense scrub status

[Graham Cobb <g.btrfs@cobb.uk.net>]

On 10/05/2020 02:14, Chris Murphy wrote:
> I don't know how the kernel and user space communicate scrub progress.
> I don't see anything in sysfs.

I did some work on btrfs-scrub a while ago to fix a bug in the way
last_physical was being saved between cancel and restore.

If I remember correctly, the way this works is that the scrub process
receives stats about the scrub progress directly from the kernel on a
socket it creates in /var/lib/btrfs, then writes updated stats into a
file in /var/lib/btrfs/scrub.status.<UUID> to share with scrub status
and keep a record. At the end of the scrub, the final stats are provided
by the kernel into a buffer provided in the ioctl which are also then
used to update the scrub.status file.

I don't remember how often the stats are received from the kernel but it
is frequently (not just at the end).

Unless I am confused, if the bytes scrubbed numbers are going up, then
the progress updates are being received from the kernel. The update
includes the last_finished so there should be no way the scrub process
can receive updated bytes scrubbed numbers without updated last_finished
from the kernel.

HOWEVER, I think (I may be wrong) btrfs scrub status normally reads the
stats from the file, not directly from the kernel. So it is actually
reporting the data in the file written by scrub process. That does
processing on the numbers (that was where the bug was which I found). It
is possible there is still a bug in that processing -- if so it is
possible that last_finished in the file could be zero even though it was
received as non-zero from the kernel. So, we can't be sure, without
adding logging to the scrub command, whether the kernel is really
reporting zero.

This is from memory. Sorry, I don't have time, at the moment, to go back
to the scrub usermode code to check.