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.
