MDADM 4.2 Released For Managing Linux Software RAID

[phoronix]

Phoronix: MDADM 4.2 Released For Managing Linux Software RAID

The mdadm utility for managing Linux software RAID arrays is out with a new release -- its first in more than three years...

https://www.phoronix.com/scan.php?page=news_item&px=MDADM-4.2

[piorunz]

mdadm is broken by design. Doesn't deal with bit rot...

[coder]

mdadm is broken by design. Doesn't deal with bit rot...

You're supposed to scrub your RAID and replace any drives that fail.

Modern HDDs internally do a patrol scrub and relocate sectors with too many (correctable) errors. That's how bit rot is handled. A failed read then indicates a drive that's too far gone to be reliable.

[adriansev]

you can always use "repair" instead of "check" when verifying the array, and/or additionally you can use dm-integrity on top of a md-raid dev (so you can scrub the actual data and correlate with a "check" result of md-raid, so you can take decision on repair and establish the "good" device in a even component mirroring array)

[MrCal]

Even after this update I assume mdadm is still vulnerable to arrays with drives that lack support of SCTERC (also called TLER by WD and ERC/SCT by Seagate).
Most SATA SSD doesn't come with SCTERC anymore, even NAS drives which are supposed to be used in RAID arrays like WD RED and Seagate IronWolf (even Pro doesn't have SCTERC).

Was puzzled me about this was that the NAS manufacturers do have these drives on their support list, which at first doesn't make sense because they mostly use mdadm. I asked QNAP support and the answer was: "We have other timing implementations, along with ERC, for disk health monitoring and error handling.".

Rumor has it that ZFS doesn't rely on SCTERC either. Would be nice to see mdadm moving in the directing too. (I'm away of the hack to increase the kernel-driver-timeout, but mdadm should just kick out a drive from the array if it doesn't respond e.g. within 10 seconds even without receiving any SCTERC command from the drive)

In regards to bit-rot. you can actually get integrity protection with mdadm using dm-integrity.
Example of a storage setup with integrity, RAID, crypt and LVM: dm-integrity > md > dm-crypt > lvm > ext4
(or use stratis, same-same I assume :-P)

[piorunz]

You're supposed to scrub your RAID and replace any drives that fail.

Modern HDDs internally do a patrol scrub and relocate sectors with too many (correctable) errors. That's how bit rot is handled. A failed read then indicates a drive that's too far gone to be reliable.

You are aware that bit rot can be caused not only by HDD? RAM errors for example? Cabling errors? You can have two different copies of data (due to bit rot) in RAID1 mdadm mirror, and mdadm fails to detect and fix it? It just read first available copy of data from one of the mirrors, and your data is corrupted.

[GreenReaper]

If you have bad RAM it may be roughly as likely that bad data is written, with appropriate integrity information. ECC RAM should help in both cases and should be used in any case where data integrity is a consideration.

Cabling could be an issue, I believe there are integrity solutions specifically for it (some with Linux support), however I suspect they are more likely to be provided by RAID controllers.

md helps in the majority of cases, where an error is clear and has resulted in a failed read, i.e. it may use redundant copies to restore it, which will result in a write to disk in an attempt to restore the redundancy.

md is not intended to detect faulty hardware that returns incorrect values. If you want a greater guarantee against that, file-level checksums or a filesystem or integrity layer providing block-level checksums is appropriate.

[waxhead]

mdadm is broken by design. Doesn't deal with bit rot...

Nonsense! It is NOT broken by design - it was never designed to deal with bit rot in the first place. It's purpose is to have redundancy against failed disks, not bit rot.

It is not a secret that I am a BTRFS "enthusiast" and I moved a large array from mdraid to BTRFS and have stopped using mdraid for the most part precisely because of bit rot and that kind of stuff, but really - there is absolutely no reason to complain about mdraid - it is nearly perfect, and really an amazing piece of software for what it is designed for!.

The biggest problem people have with mdraid is not loosing the arrays, it is actually getting rid of them!

[piorunz]

Nonsense! It is NOT broken by design - it was never designed to deal with bit rot in the first place. It's purpose is to have redundancy against failed disks, not bit rot.

It is not a secret that I am a BTRFS "enthusiast" and I moved a large array from mdraid to BTRFS and have stopped using mdraid for the most part precisely because of bit rot and that kind of stuff, but really - there is absolutely no reason to complain about mdraid - it is nearly perfect, and really an amazing piece of software for what it is designed for!.

The biggest problem people have with mdraid is not loosing the arrays, it is actually getting rid of them!

You are contradicting yourself.

"It is NOT broken by design"
it was never designed to deal with bit rot"

in other words... BROKEN BY DESIGN. It has been designed in the way which allows bit rot and corruption of all your data (because of many reasons). It's broken.

[lacek]

You are contradicting yourself.

"It is NOT broken by design"
it was never designed to deal with bit rot"

in other words... BROKEN BY DESIGN. It has been designed in the way which allows bit rot and corruption of all your data (because of many reasons). It's broken.

People have been using that for years and it did work. What changed is that disk grew much larger and require more error checking than before. Design was not bad, it was good for its time.

Also one is supposed to keep backups which are most relevant for ensuring data perseverance. Did you burn your data to optical drives so that it survives next Carrington event?