I hope friends who use raidZ can help answer some of my basic questions.

[PPT1063]

The following is from a translation:
I’ve recently been learning about raid technologies and have some very, very basic questions. I look forward to any answers or guidance to relevant articles.

1. When using raidZ, does reading verify (check) the PQR checksum? Or does it not check?
2. In ZFS, do checksums (like fletcher, sha256) generate PQR checksums just like the data?
3. I know QR checksums use Reed-Solomon checksums; I’ve seen a system that, although it uses Reed-Solomon for a RAID6, during data verification it doesn’t use the checksum to correct errors, but instead directly generates new PQ checksums. I want to know, when raidZ finds errors, does it use Reed-Solomon checksums to correct them?
4. Bit flip situations. I’m curious, how does raidZ handle raidZ1? If there is an error, can the checksum locate which disk it’s on? If it can’t, is it up to the user to handle it, or does it default to a checksum error?
5. Bit flip situations. Normal RAID6, based on PQ checksums, can correct any one error. R checksums are based on Reed-Solomon 2^2. I guess that raidZ3 doesn’t extend correction capability and can still only correct one error. Is my guess correct, or can raidZ3 correct more?
6. Some systems process RAID5/6 per byte. I saw raidZ extend to 8-byte processing; can this improve safety?

Thanks to everyone who might help.

[amotin]

1. Normal reads do not read PQR columns if all data columns are available, only scrubs or error recovery do.
2. Block checksums are calculated on top of RAIDZ, so they don't depend on the PQR details. But blocks storing the block checksums as part of block pointers are obviously also protected by their own PQR (or whatever redundancy is used by vdev where that block is stored).
3. When ZFS detects block checksum mismatch, it reads all available parity columns and tries to find a combination of them, that would produce a valid block checksum. I don't think it can currently recover situation when all columns have some bit flips in different places, which I guess could possibly be done in some cases, but it should be extremely rare, while 1/2/3 disks failing completely is much more probable.
4. Same answer as the previous. RAIDZ tries to find a combination of available disks/columns that would satisfy the block checksum. In some cases of fragmented pools number of combinations to try may grow exponentially, so ZFS may not always try all of them, but it tries harder than user would likely do.
5. RAIDZ3 combined with block checksums can reliably correct up to 3 disks/columns reading complete garbage. But AFAIK it is not tuned to correct many individual bit flips randomly scattered through more than 3 disks. As I answered on question 3, I think available amount of parity may allow to implement it, but probability of such scenario is extremely low.
6. I may be wrong here, but I think it is just a vectorization to improve performance.

[PPT1063]

Here’s the translation from earlier:
Thanks, that’s a really convincing answer.
I want to follow up on point five, I’m a bit confused here.
I want to assume a scenario: 1~6 bytes. 123 is data, 456 corresponds to PQR. When 1 and 2 occur, the bits are flipped. As I understand it, P exactly cancels out, so no anomaly appears. QR might realize there’s an issue, or might not (this is beyond the capability of Reed-Solomon error correction). In this case, as I understand it, the data can no longer be corrected, and RAIDZ can only try to reconstruct. Is my understanding reasonable?
This is the last question, looking forward to your reply.

[amotin]

As I have told, ZFS won't even look on PQR columns until block checksum mismatch is detected. Block checksums are much more reliable for that purpose. Once the mismatch is detected, ZFS will read all the parity blocks and find a working combination.

[PPT1063]

Thank you so much! You’re really helpful. I’ll close this issue now.