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
<ce3g8...@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).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
