At 09/22/2016 11:07 AM, Christoph Anton Mitterer wrote:
On Thu, 2016-09-22 at 10:08 +0800, Qu Wenruo wrote:
And I don't see the necessary to csum the parity.
Why csum a csum again?

I'd say simply for the following reason:
Imagine the smallest RAID5: 2x data D1 D2, 1x parity P
If D2 is lost it could be recalculated via D1 and P.

What if only (all) the checksum information for D2 is lost (e.g.
because of further silent data corruption on the blocks of these

First thing first, csum is metadata, which is normally protected by metadata profile.

So, you are saying the csum tree is corrupted.
Wow, that's protected by RAID5(assume you're using RAID5 for both metadata and data) and tree leaf csum.
If that happens, which means at least 2 devices are already corrupted.

Your data is doomed anyway.

Then we'd only know D1 is valid (which still has working csums).

If that really happens, csum tree leaf is corrupted, and your D1 csum will be corrupted too, considering how close they are.

No means to recover anyway.

But we
wouldn't know whether D2 is (because gone) neither whether P is
(because not csummed).
And next imagine silent data corruption in either D2 or P => we cannot
tell which of them is valid, no repair possible... or do I miss

Stated above, your fs is already screwed up in that case.

The biggest problem is, parity is a block level thing (its bytenr are dev bytenr, not logical bytenr), and csum is logical level thing.

Screwing these things up will cause more problem and more time to maintain than the benefit.

Just as you expected, it doesn't check parity.
Even for RAID1/DUP, it won't check the backup if it succeeded
the first stripe.
That would IMO be really a highly severe bug... making scrubbing close
to completely useless for multi-device fs.
I mean the whole reason for doing it is to find [silently] corrupted
blocks... in order to be able to do something about it.
If on would only notice if the read actually fails because the one
working block is also gone.. then why having a RAID in the first place?

That's "--check-data-csum", not in-kernel scrub.


Current implement doesn't really care if it's the data or the copy
corrupted, any data can be read out, then there is no problem.
Except it makes RAID practically useless... => problem


To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
More majordomo info at

Reply via email to