Howdy,
Thanks both for the answer.
On Mon, Sep 04, 2017 at 11:49:44PM -0400, Phil Turmel wrote:
> > Given this, what is the suggested course of action?
>
> Do a "repair" scrub (once) instead of a check scrub to fix the parity.
> The data blocks themselves (the ones you care about) must be OK since
> btrfs is happy.
>
> If future check scrubs keep running into this, investigate if the ranges
> reported are all falling on a particular disk, and look for hardware issues.
On Tue, Sep 05, 2017 at 08:25:58AM +0200, Mikael Abrahamsson wrote:
> If the data section is fine (which it seems to be because btrfs is happy),
> then you should issue "repair" to correct parity.
>
> "echo repair > /sys/block/mdX/md/sync_action"
So you're both saying the same thing on how to fix it, but do we agree
that somehow it's my parity data that went wrong since the filesystem
seems fine?
Do we also agree that "mistmatch sector" means that the parity does not
add up, and that in a raid5 scenario, the md layer has no idea which of
the drives has bad data, just that things don't add up?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
