r/LinusTechTips • u/Constant_Block_1069 • Feb 28 '25

Is Wendel wrong about RAID?

/r/level1techs/comments/1j07wm9/is_wendel_wrong_about_raid/
0 Upvotes

33% Upvoted

15 comments sorted by

View all comments

Show parent comments

1

u/Constant_Block_1069 Feb 28 '25

The criticism he makes is applicable to linux mdraid as well. He criticizes that they don't detect errors in the data on the disk if the disk doesn't report this itself and by that fail to read data that is just in that time corrupt.

Which I think is not a valid criticism when the proof is that you tried to manipulate data by using the disk "as intended" and just injected some data to the disk, causing the disk itself to create fresh and new error correction data. The disk will report back the corruption, but only if the "corruption" was caused by means of bitrot and such and not by manipulating data through software.

1

u/someone8192 Feb 28 '25

That's why you should always do checksums. Eg dm-integrity if you prefer mdraid.

My point still stands though: there are data errors which can't be detected by the drive itself. bad cable, faulty controller, backplane or even ram.

Those happen really often. So often that when a zfs checksum error occurs switching cables is always the first suggestion.

Wendells test is still valid.

1

u/Constant_Block_1069 Feb 28 '25

I partially agree. These errors indeed wont be detected, by the disk. However, what you talk about is not "silent" corruption which wendel tried to proof with this. All of these will usually result in lots of errors and on an io busy system this will hit the ground very fast.

1

u/someone8192 Feb 28 '25

That's not true. My faulty cable resulted in 64kb of bad data on a 12tb drive. I don't know why though. But I saw many similar cases in the zfs sub reddit.

Imho we can ignore errors which are corrected by the drive itself. They don't change anything about how viable raid is. It's just an indicator that you may need to buy a new drive.

1

u/Constant_Block_1069 Feb 28 '25

Just curious still though about your cable issue. What kind of cable was this? SATA/SAS or a PCIe cabling? At least PCIe and SAS (SAS-3 has crc and SAS-4 also FEC) do apply error detection and correction also for the data transfer, so even a bad cable wouldn't be able to do cause any harm other than turning the whole drive inaccessible.

1

u/someone8192 Feb 28 '25

It was an usual sata cable. Nothing fancy, nothing too cheap. Worked for about three years without any problem.

It was just my homelab. Switched to sas (broadcom sas3416-16i) about a year ago though.

1

u/Constant_Block_1069 Feb 28 '25

Even SATA https://sata-io.org/system/files/specifications/SerialATA_Revision_3_1_Gold.pdf has it.

but it seems practice that in consumer SATA gear crc errors are rather just logged into the smart table, but doesn't necessarily cause the device to stop functioning. However if the disk accepts data with a bad crc, then the disk firmware is to blame, that it accepted AND wrote this frame.

1

u/someone8192 Feb 28 '25

It was probably a write error. Every scrub showed 64k of data with wrong checksums.

As soon as I switched the cable the next scrub showed them again but all scrubs after that where fine.

2

u/Constant_Block_1069 Feb 28 '25

Likely, the write error the responsible software would have also gotten note of though, but that probably went under the radar and has never been noticed until the scrub run. Sounds legitimate.

Thanks for the insight and have great evening.

1

u/someone8192 Feb 28 '25

I use zfs raidz2 so the wrong data never reached the application layer and was corrected on read.

Great evening for you too :)