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:[1]
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:[2]
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.[3]
Ursache für mismatch_cnt
Wird im folgenden Posting von Neil Brown erklärt: [4]. 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[5]):
- Über sysfs:
echo check > /sys/block/mdX/md/sync_action
- Ü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:[6]
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).[7]
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
- ↑ checkarray README (/usr/share/doc/mdadm/README.checkarray)
- ↑ How to force rewrite of a smart detected bad block with raid5 (marc.info)
- ↑ md README (/usr/share/doc/mdadm/md.txt.gz)
- ↑ the issue with mismatch_cnt (bugs.debian.org)
- ↑ Re: Check/repair command? (linux-raid mailing list, Neil Brown, 31.03.2014)
- ↑ mdadm: Rebuild20 event detected on md device (Blog, 06.08.2007)
- ↑ Libata error messages - ATA error expansion (ATA Wiki)
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. |