Linux RAID subsystem development
 help / color / mirror / Atom feed
From: anthony <antmbox@youngman.org.uk>
To: David Niklas <simd@vfemail.net>, Wol <antlists@youngman.org.uk>
Cc: Linux RAID <linux-raid@vger.kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: Need help increasing raid scan efficiency.
Date: Tue, 3 Jun 2025 21:27:35 +0100	[thread overview]
Message-ID: <b23b6075-e177-4a85-b34b-e7f5feb95291@youngman.org.uk> (raw)
In-Reply-To: <20250603160415.61c9ca7c@Zen-II-x12.niklas.com>

On 03/06/2025 21:04, David Niklas wrote:
> Searching online turned up raid6check.
> https://unix.stackexchange.com/questions/137384/raid6-scrubbing- 
> mismatch-repair
> 
> But the people there also pointed out that Linux's raid repair operation
> only recalculates the parity. I would have thought that it did a best of
> 3 option. I mean, that's a big part of why we have RAID6 instead of RAID5,
> right?

 From what I remember of raid6check, it actually does a proper raid 6 
calculation to recover the damaged data.

Raid 5 certainly just recalculates the parity, but it doesn't have any 
choice. Because it can only reconstruct ONE piece of information, it can 
detect the corruption, but it has no idea WHAT is corrupted. So it 
assumes (with good reason) that it's the parity and re-calculates it. 
Where raid 5 scores is if you lose a block, or a drive, or whatever, it 
is told what has been lost and can recreate it. If your data is 
corrupted, however, it has two pieces of missing information ("what" and 
"where"), and can only reconstruct one, so it assumes it's the parity 
that's been lost.

Because raid-6 has two levels of redundancy, if ONE block is damaged, it 
can work out both what and where, which is what raid6check does.

I've done it slightly differently, I've got raid-5 sat on top of 
dm-integrity, so if a disk gets corrupted dm-integrity will simply 
return a read failure, and the raid doesn't have to work out what's been 
corrupted. I've got a different problem at the moment - my array has 
assembled itself as three spares, so I've got to fix that ... :-(

Cheers,
Wol

  parent reply	other threads:[~2025-06-03 20:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03  1:05 Need help increasing raid scan efficiency David Niklas
2025-06-03 16:46 ` Wol
2025-06-03 20:04   ` David Niklas
2025-06-03 20:04     ` David Niklas
2025-06-03 20:27     ` anthony [this message]
2025-06-04  4:22     ` Jani Partanen
2025-06-04  8:59     ` Reindl Harald
2025-06-04  8:46 ` Reindl Harald
2025-06-04 12:24   ` John Stoffel
2025-06-04 12:34 ` John Stoffel
2025-06-04 12:52   ` Reindl Harald
2025-06-04 15:45   ` David Niklas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b23b6075-e177-4a85-b34b-e7f5feb95291@youngman.org.uk \
    --to=antmbox@youngman.org.uk \
    --cc=antlists@youngman.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=simd@vfemail.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox