"C" disk type (Checksum)

I'd like to propose adding the disk type: "C" Checksum. Since unraid arrays vary in disk count (2 to 28 disks) it means a per-disk overhead would be wasteful. By tying checksum storage to array capacity we should scale better and allow us to compare against P/Q parity disks to create a quorum.

Hashing Mechanisms

• CRC64 (~10GB/s): Fast, sufficient for most bit rot scenarios and ~8 bytes/stripe

• BLAKE3 (~2GB/s): Faster than SHA256 but needs ~32 bytes/stripe

• SHA256 (~500MB/s): Thorough work horse but slow and ~32 bytes/stripe

Theoretical example:

• If we take a 100TB array and assume a 4Kb page size this gives us 109,951,162,777,600 bytes or about 26.8 billion individual stripes.

• The checksum space required would be number of stripes * bytes per stripe or in our example 214,748,364,800 bytes (195~gb)

• Additional metadata would be required such as stripe index, metadata checksums, allocation tables, alignment/padding, etc. for all intents and purposes we can just throw an overhead factor of 2x.

• In our example a 100TB array would require a checksum disk equal to or larger than 390gb

Checksums could be verified during every r/w operation if md_write_method is on. If a mismatch is detected:

1. Log the corruption event via notification

2. If recoverable via P/Q: automatically reconstruct to repair the stripe

3. If not recoverable: do something such as indicate the potential files corrupted for manual intervention

Could also schedule the verification as a background task that runs during off-peak hours similar to mover or parity checks via tuning:

• Sequentially reads all array data

• Verifies every stripe's checksum

• Detects AND repairs corruption proactively

• Optional: user-configurable frequency (weekly, monthly, etc.)