On Sun, 2016-01-03 at 15:00 +0000, Duncan wrote:

But now that I think about it, balance does read the chunk in ordered
to 
rewrite its contents, and that read, like all reads, should normally
be 
checksum verified

That was my idea.... :)

 (except of course in the case of nodatasum, which nocow 
of course implies).

Though I haven't had the time so far to reply on the most recent posts
in that thread,... I still haven't given up on the quest for
checksumming of nodatacow'ed data ;-)

So a balance completed without error /may/ 
effectively indicate a scrub would complete without error as
well.  But 
it wasn't specifically designed for that, and if it does so, it's
only 
doing it because all reads are checksum verified, not because it's 
actually purposely doing a scrub.

Well sure... this is however an interesting concept to think about for
the long term future.

I'd expect that in some distant future, we'd have powerful userland
tools that do maintenance and health monitoring of btrfs filesystems,
including e.g. automated scrubs, defrags and so on.

Especially on large filesystems all these operations tend to take large
amounts of time and may even impact the lifetime of the storage
device(s)... so it would be clever if certain such operations could be
kinda "merged", at least for the purposes of getting the results.
As in the above example, if one would anyway run a full balance, the
next scrub may be skipped because one is just doing one.
Similar for defrag.

And even if balance works to verify no checksum errors, I don't
believe 
it would correct them or give you the detail on them that a scrub
would.

I'd have expected that that read errors are (if possible because of
block copies) are repaired as soon as they're encountered... isn't that
the case?

  

And if there is an error, it'd be a balance error, which might or
might 
not actually be a scrub error.

Sure, but it shouldn't be difficult to collect e.g. scrub stats during
balance as well.


:-)

Cheers,
Chris.