Re: using the raid6check report
From: Eyal Lebedinsky <hidden>
Date: 2017-01-09 02:13:39
On 09/01/17 12:56, NeilBrown wrote:
quoted hunk ↗ jump to hunk
On Mon, Jan 09 2017, Eyal Lebedinsky wrote:quoted
I am aware of that discussion and agree with the sentiment (fix in user space).(I primarily provided for the information of others)quoted
What I miss is a message from md when a 'check' mismatch is found. Not having this means I have to run 'raid6check', then after looking at the situation run 'raid6check autorepair' in the small sections reported as bad. This is time consuming and risky.Something like this?diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 69b0a169e43d..f19c38baf2b2 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c@@ -2738,6 +2738,8 @@ static void handle_parity_checks5(raid5_conf_t *conf, struct stripe_head *sh, conf->mddev->resync_mismatches += STRIPE_SECTORS; if (test_bit(MD_RECOVERY_CHECK, &conf->mddev->recovery)) /* don't try to repair!! */ + pr_debug("%s: \"check\" found inconsistency near sector %llu\n", + md_name(conf->mddev), sh->sector); set_bit(STRIPE_INSYNC, &sh->state); else { sh->check_state = check_state_compute_run;I chose pr_debug() because I didn't want to flood the logs if there are lots of inconsistencies. You can selectively enable pr_debug() messages by writing to /sys/kernel/debug/dynamic_debug/control providing you have dynamic debugging compiled in.
I run fedora and can see the dynamic debugging control file.
Maybe use pr_info_ratelimited() instead??
Yes, rate limiting is probably a good idea when we have a really bad day.
NeilBrown
-- Eyal Lebedinsky (eyal@eyal.emu.id.au)