On 05/12/2019 03:15, Zygo Blaxell wrote: > v2 changes: > > So far this patch has had one user, who reported a bug: the manual > page for btrfs scrub said the start/end position arguments were extent > bytenr aka logical addresses, when they are in fact device offset aka > physical addresses. I am wondering to what extent this feature depends on undocumented (and possibly not even valid) behaviour of the scrub kernel operation. I think that the current code only depends on the fact that the scrub operation guarantees that "if the 'last physical` value from the previous call is provided as the start point to the next call, the scrub will continue where it left off and will eventually cover the whole filesystem (assuming there have no been changes)". This code depends on a much stronger statement which is that the scrub proceeds in order and guarantees to scrub exactly the physical blocks between start and end, in order. The reason for raising this is that I believe I have seen cases (when using cancelled and resumed scrubs) where 'last physical' has gone down. I had planned to test this last statement to see if I could reproduce the behaviour but I haven't had time. Graham
