How can RAID deal with inconsistent data?

Solution 1:

RAID VOLUMES WITH PARITY STRIPE

On the Areca controllers we use (and all modern hardware RAID controllers) during a consistency check the controller can detect if the corruption is with the parity data, the physical data on disk, or both. Most controllers accomplish this with simple checksum bits for on the parity data and data-on-disk.

In the case of the parity data being corrupted, the controller will notice the issue when you run a consistency check and re-read the physical disk for the correct bits and re-write the parity stripe. Users will see no problems because they are reading data-on-disk when opening the files. Resaving anything that causes the corrupted parity stripe to be re-written will also fix the issue.

If you have the opposite occur, and a bit flips in your actual data-on-disk, then your controller will look at the parity stripe during a consistency check to see if it has changed. In this case the controller will overwrite the data on the disk to match the parity data, which it can confirm is unchanged/good. Users will get a CRC error, or a corrupted file depending on what the data is until a consistency check is run and corrects the error.

Since parity data for specific data-on-disk is never stored on the same drive as the actual data, a single drive failure shouldn't cause any data corruption issues. Or two disks for RAID6, etc.

Consistency checks keep your data accurate as possible and if you let corrupted data sit on your volume for long enough it could get written into parity data, meaning the file is corrupted for good and will need to be restored from a backup. If a drive is in a pre-fail state where it is showing errors during consistency checks replace the drive immediately instead of waiting for the controller to mark it as failed. We run consistency checks daily on smaller volumes and weekly on larger ones.

RAID VOLUMES WITHOUT PARITY STRIPE (EX. RAID1)

The hard drive controller/firmware may be able to correct the issue. If this is not possible the RAID controller will have a very hard time fixing the issue. In this case you would probably have to read the drives individually to recover the data.

GENERALLY SPEAKING

Run consistency checks at the interval recommended by your RAID card mfg. If you are really worried about corruption, you can also stack a resilient file system over a RAID volume. Modern resilient file systems can correct many of these data integrity issues and stacking a resilient FS over RAID6 would offer you excellent data uptime, without corruption. And even with 2 simultaneous drive failures you would still have FS parity data available to avoid presenting corrupted data to the user.

Solution 2:

You effectively describe the situation, where one disk writes (or reads) an error. The RAID controller has no practical (e.g. write and read-back would kill your performance) way to protect against this situation. It has to rely on the disks being able to detect this kind of error and either use a different block or bail out of the volume - causing a degradation of the RAID.

If you think about the single-disk situation, the only protection against inconsistent writes (or reads) is the disk itself. RAID builds upon that, but does not introduce an additional safeguard.

N.B. I know from experience that XFS reacts quite sensible to erroneous disks in an array. So at least my non-low-end controllers and the OS did recognize but not protect against that inconsistency (a known to be faulty disk was added forcefully to a volume).