Re: Adventures in btrfs raid5 disk recovery

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-06-27 23:17, Zygo Blaxell wrote:
> On Mon, Jun 27, 2016 at 08:39:21PM -0600, Chris Murphy wrote:
>> On Mon, Jun 27, 2016 at 7:52 PM, Zygo Blaxell
>> <ce3g8jdj@umail.furryterror.org> wrote:
>>> On Mon, Jun 27, 2016 at 04:30:23PM -0600, Chris Murphy wrote:
>>>> Btrfs does have something of a work around for when things get slow,
>>>> and that's balance, read and rewrite everything. The write forces
>>>> sector remapping by the drive firmware for bad sectors.
>>>
>>> It's a crude form of "resilvering" as ZFS calls it.
>>
>> In what manner is it crude?
>
> Balance relocates extents, looks up backrefs, and rewrites metadata, all
> of which are extra work above what is required by resilvering (and extra
> work that is proportional to the number of backrefs and the (currently
> extremely poor) performance of the backref walking code, so snapshots
> and large files multiply the workload).
>
> Resilvering should just read data, reconstruct it from a mirror if
> necessary, and write it back to the original location (or read one
> mirror and rewrite the other).  That's more like what scrub does, except
> scrub rewrites only the blocks it couldn't read (or that failed csum).
It's worth pointing out that balance was not designed for resilvering, 
it was designed for reshaping arrays, converting replication profiles, 
and compaction at the chunk level.  Balance is not a resilvering tool, 
that just happens to be a useful side effect of running a balance 
(actually, so is the chunk level compaction).