Linux Software Raid runs checkarray on the First Sunday of the Month? Why?

Question

It looks like Debian has a default to run checkarray on the first Sunday of the month.

This causes massive performance problems and heavy disk usage for 12 hours on my 2TB mirror. Doing this "just in case" is bizzare to me. Discovering data out of sync between the two disks without quorum would be a failure anyway.

This massive checking could only tell me that I have an unrecoverable drive failure and corrupt data. Which is nice, but not all that helpful. Is it necessary?

Given I have no disk errors and no reason to believe my disks have failed, why is this check necessary? Should I take it out of my cron?

/etc/cron.d# tail -1 /etc/cron.d/mdadm
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet

Thanks for any insight,

Answer 1

Since it sounds like you are running RAID1, I agree that you don't need the check in your situation, but I disagree with some of the reasons given by the first answerer.

1) RAID is an UPTIME/ACCESS SPEED solution, not a backup solution. Having the RAID fail shouldn't mean data loss as you shouldn't be using it for that.

2) I'm curious why you think mirroring the entire drive is "Inefficient." Why add complexity and have to rely on the computer not missing something when you can just mirror everything?

3) "Risky because in case of disk failures, rebuilding a mirror or parity disk for large and active arrays can take days - in this interval if another disk from degraded array fails it means data loss." As opposed to what, keeping everything on a single disk? RAID isn't perfect but it does mean that you can survive an entire drive dying without losing access to your data, and can REBUILD without losing access to your data. Also, on anything OTHER than RAID1, the periodic testing can detect a drive that is becoming bad (it keeps track of individual block failures for a particular drive, and also uses SMART data) and can flag it as failed BEFORE you lose access to the data. Immediate, catastrophic drive failure is not the only data loss scenario.

Answer 2

The fact that Debian's mdadm package makes it easy to turn off the monthly checkarray suggests to me that it's not really critical. Here's the relevant message you get from dpkg-reconfigure mdadm:

If the kernel supports it (versions greater than 2.6.14), mdadm can periodically check the redundancy of MD arrays (RAIDs). This may be a resource-intensive process, depending on the local setup, but it could help prevent rare cases of data loss. Note that this is a read-only check unless errors are found; if errors are found, mdadm will try to correct them, which may result in write access to the media.

Personally, I don't have a problem with the checkarray script running once a month on my 1TB mirror (a simple file server), since it takes less than 3.5 hours on a Sunday morning, while nothing else is happening anyway. In cases where the checkarray is causing noticeable performance problems, I would not hesitate to turn it off, or, perhaps, schedule it to run less frequently (e.g. every 6 months, during certain holidays, etc.).

Answer 3

I agree zfs & btrfs look like an interesting solution compare to normal mdadm RAID5 (in some situations).

But...

• btrfs does not have a stable version. you really wanna risk this one?
• zfs seems mature - but the solution for linux systems ... is a bit patchy. FUSE? 3rd party native kernel modules?

I say stick with native support - on LVM2 on mdadm RAID1/5/6 ...

my two cents.

Answer 4

Yes, take it out. Anyway, RAID on arrays with large disks (>200G) is:

• Inefficient because RAID mirrors even the space that is not in use.
• Risky because in case of disk failures, rebuilding a mirror or parity disk for large and active arrays can take days - in this interval if another disk from degraded array fails it means data loss.

There is a couple modern filesystem/lvms promising to address these issues, like zfs and btrfs.