Mdadm checkarray

Hinweis: Bitte beachten Sie, dass dieser Artikel / diese Kategorie sich entweder auf ältere Software/Hardware Komponenten bezieht oder aus sonstigen Gründen nicht mehr gewartet wird. Diese Seite wird nicht mehr aktualisiert und ist rein zu Referenzzwecken noch hier im Archiv abrufbar.

Dieser Artikel liefert Informationen über das Script checkarray des Linux Software RAID Tools mdadm und wie es ausgeführt wird. Checkarray prüft durch Leseoperationen die Konsistenz der RAID-Platten. Im Fehlerfall werden Schreibvorgänge vorgenommen, die die Performance des RAIDs beeinträchtigen können. Weitere Informationen sind unter /usr/share/doc/mdadm/README.checkarray zu finden.

Fehlerbehandlung bei Checks

Checkarray prüft durch Leseoperationen die Konsistenz der RAID-Platten. Es vergleicht die korrespondierenden Blöcke jeder Platte im Array. Im Fehlerfall wird der Zähler in der Datei /sys/block/mdX/md/mismatch_cnt erhöht. Laut der README zu checkarray wird im Fehlerfall wie folgt reagiert:

If, however, while reading, a read error occurs, the check will trigger the normal response to read errors which is to generate the 'correct' data and try to write that out - so it is possible that a 'check' will trigger a write. However in the absence of read errors it is read-only.

Diese automatische Repair-Funktion wird auch von Neil Brown in einem Mailing-List-Post erwähnt:

All you need to do is get md/raid5 to try reading the bad block. Once it does that it will get a read error and automagically try to correct it. [...] 'check' (i.e. echo check > /sys/block/mdXX/md/sync_action) will cause md/raid5 to read all blocks on all devices, thus auto-repairing any unreadable blocks.

Check vs. Repair

Im Gegensatz zu Check beinhaltet ein Repair auch einen Resync. Der Unterschied zum Resync ist dabei, dass keine Bitmap zur Optimierung des Prozesses verwendet wird.

Ursache für mismatch_cnt

Wird im folgenden Posting von Neil Brown erklärt: . Die md man Page gibt auch Hinweise dazu:

On a truly clean RAID5 or RAID6 array, any mismatches should indicate a hardware problem at some level - software issues should never cause such a mismatch. However on RAID1 and RAID10 it is possible for software issues to cause a mismatch to be reported. This does not necessarily mean that the data on the array is corrupted. It could simply be that the system does not care what is stored on that part of the array - it is unused space. The most likely cause for an unexpected mismatch on RAID1 or RAID10 occurs if a swap partition or swap file is stored on the array.

Automatischen Check durchführen

Der automatische Check wird an jedem Sonntag im Monat um 00:57 Uhr aufgerufen. Jedoch wird die Ausführung verhindert wenn der Tag nicht kleiner oder gleich dem 7 Tag des Monats entspricht. Also wird der Job nur einmal im Monat am ersten Sonntag ausgeführt. Zusätzlich versucht cron den Check mit der mit Priorität idle auszuführen, um das System nicht zu sehr auszulasten. vi /etc/cron.d/mdadm zeigt die Konfiguration des Cronjobs.

Auszug:

By default, run at 00:57 on every Sunday, but do nothing unless the day of the month is less than or equal to 7. Thus, only run on the first Sunday of each month. crontab(5) sucks, unfortunately, in this regard; therefore this hack (see #380425).

Manuellen Check durchführen

Ein manueller Check kann über das sysfs oder das Skript checkarray gestartet werden (mdadm hat dazu noch keine Option):

1. Über sysfs:
   • echo check > /sys/block/mdX/md/sync_action
2. Über das Skript checkarray:
   • /usr/share/mdadm/checkarray /dev/mdX

Visualisierung

Während des Checks wechselt die Ausgabe von

root@ubuntumdraidtest:~# cat /sys/block/md0/md/sync_action
idle

auf

root@ubuntumdraidtest:~# cat /sys/block/md0/md/sync_action
check

cat /proc/mdstat liefert während des Checks folgende Ausgabe:

Every 2.0s: cat /proc/mdstat                                                      Wed Sep 25 15:15:25 2013

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[0] sdc1[1]
      2095040 blocks super 1.2 [2/2] [UU]
      [======>..............]  check = 34.1% (716160/2095040) finish=0.0min speed=238720K/sec

unused devices: <none>

Der zugehörige dmesg Auszug:

[12294.966072] md: data-check of RAID array md127
[12294.966074] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[12294.966075] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
[12294.966077] md: using 128k window, over a total of 2095040k.
[12305.660042] md: md127: data-check done.

Check pausieren

Folgender Befehl

• pausiert den Check und bricht ihn nicht ab
• bei einem erneuten Aufruf von checkarray -a /dev/mdX wird der Check weitergeführt

root@ubuntumdraidtest:~# /usr/share/mdadm/checkarray -x /dev/mdX

Rebuild40 Event

Treten bei einem Check Lesefehler auf einem Device auf, versucht das Software RAID die Daten mit Hilfe der anderen RAID-Devices zu rekonstruieren und diese auf das betroffene Device wieder zu schreiben. In diesem Fall können im syslog RebuildNN Meldungen auftreten (z.B. Rebuild25, Rebuild40, ..., Rebuild99). Die zwei Ziffern beschreiben dabei, bei wie viel Prozent des Checks das Rebuild-Event auftrat:

adminuser@wc2:~$ tail -f /var/log/syslog
May  9 11:11:27 wc2 mdadm[1508]: Rebuild25 event detected on md device /dev/md/3
May  9 11:28:07 wc2 mdadm[1508]: Rebuild40 event detected on md device /dev/md/3
[...]
adminuser@wc2:~$ date && cat /proc/mdstat 
Fr 9. Mai 11:30:42 CEST 2014
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
[...]
md3 : active raid1 sdb5[1] sda5[0]
      454100403 blocks super 1.2 [2/2] [UU]
      [========>............]  check = 42.4% (192666240/454100403) finish=137.6min speed=31657K/sec
[...]
adminuser@wc2:~$ tail -f /var/log/syslog
May  9 12:01:27 wc2 mdadm[1508]: Rebuild69 event detected on md device /dev/md/3
May  9 12:18:07 wc2 mdadm[1508]: Rebuild82 event detected on md device /dev/md/3
[...]
wfischer@wc2:~$ date && cat /proc/mdstat 
Fr 9. Mai 12:18:18 CEST 2014
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
[...]
md3 : active raid1 sdb5[1] sda5[0]
      454100403 blocks super 1.2 [2/2] [UU]
      [================>....]  check = 82.4% (374380288/454100403) finish=306.8min speed=4330K/sec
[...]
adminuser@wc2:~$ tail -f /var/log/syslog
May  9 15:34:50 wc2 kernel: [19188.038973] ata1.00: exception Emask 0x0 SAct 0xe SErr 0x0 action 0x0
May  9 15:34:50 wc2 kernel: [19188.039346] ata1.00: irq_stat 0x40000008
May  9 15:34:50 wc2 kernel: [19188.039567] ata1.00: failed command: READ FPDMA QUEUED
May  9 15:34:50 wc2 kernel: [19188.039863] ata1.00: cmd 60/00:08:ba:99:0e/04:00:3e:00:00/40 tag 1 ncq 524288 in
May  9 15:34:50 wc2 kernel: [19188.039865]          res 41/40:00:bd:9a:0e/00:00:3e:00:00/40 Emask 0x409 (media error) <F>
May  9 15:34:50 wc2 kernel: [19188.040781] ata1.00: status: { DRDY ERR }
May  9 15:34:50 wc2 kernel: [19188.040999] ata1.00: error: { UNC }
May  9 15:34:50 wc2 kernel: [19188.045186] ata1.00: configured for UDMA/133
May  9 15:34:50 wc2 kernel: [19188.045202] ata1: EH complete
May  9 15:35:35 wc2 kernel: [19232.447063] md: md3: data-check done.
May  9 15:35:35 wc2 mdadm[1508]: RebuildFinished event detected on md device /dev/md/3, component device  mismatches found: 128 (on raid level 1)

Anmerkung: Der ATA Error UNC in diesem Beispiel bedeutet Uncorrectable error (often due to bad sectors on the disk).

mismatch_cnt mit Icinga/Nagios überwachen

Ein einfaches Script überwacht den mismatch_cnt mit Icinga/Nagios und retourniert Warning/Critical, wenn gegebene Schwellwerte überschritten werden:

$ sudo vi /usr/lib/nagios/plugins/check_linux_raid_mismatch
#!/bin/bash
#template from http://www.juliux.de/nagios-plugin-vorlage-bash
WARN_LIMIT=$1
CRIT_LIMIT=$2
if [ -z $WARN_LIMIT ] || [ -z $CRIT_LIMIT ];then
echo "Usage: check_linux_raid_mismatch WARNLIMIT CRITLIMIT"
exit 3;
else
DATA=-1
for file in /sys/block/md*/md/mismatch_cnt
do
  DATA2=`cat $file`
  DATA=$((DATA + DATA2))
  MD_NAME=`echo $file | awk 'BEGIN { FS = "/" } ; { print $4 }'`
  PERF_DATA+="$MD_NAME=`cat $file` "
done
if [ $DATA -eq -1 ]; then
echo "UNKNOWN - software raid mismatch_cnts not found | $PERF_DATA"
exit 3;
fi
if [ $DATA -lt $WARN_LIMIT ]; then
echo "OK - all software raid mismatch_cnts are smaller than $WARN_LIMIT | $PERF_DATA"
exit 0;
fi
if [ $DATA -ge $WARN_LIMIT ] && [ $DATA -lt $CRIT_LIMIT ]; then
echo "WARNING - software raid mismatch_cnts are greater or equal than $WARN_LIMIT | $PERF_DATA"
exit 1;
fi
if [ $DATA -ge $CRIT_LIMIT ]; then
echo "CRITICAL - software raid mismatch_cnts are greater or equal than $CRIT_LIMIT | $PERF_DATA"
exit 2;
fi
if [ $DATA -eq -1 ]; then
echo "UNKNOWN - software raid mismatch_cnts not found | $PERF_DATA"
exit 3;
fi
fi

Das Script kann wie folgt aufgerufen werden:

$ /usr/lib/nagios/plugins/check_linux_raid_mismatch 1 10
OK - all software raid mismatch_cnts are smaller than 1 | md0=0 md1=0 md2=0 md3=0 md4=0

Einzelnachweise

Autor: Thomas Niedermeier Thomas Niedermeier arbeitet im Product Management Team von Thomas-Krenn. Er absolvierte an der Hochschule Deggendorf sein Studium zum Bachelor Wirtschaftsinformatik. Seit 2013 ist Thomas bei Thomas-Krenn beschäftigt und kümmert sich unter anderem um OPNsense Firewalls, das Thomas-Krenn-Wiki und Firmware Sicherheitsupdates.