Seit Sonntag beschäftigt sich mein Homeserver mit sich selbst und reagiert nur noch mit großer Verzögerung auf Anfragen der Clients. Außerdem binden die Clients die Serververzeichnisse nicht mehr richtig ein – soll heißen: Nur noch jeweils ein Client hat Zugriff, die anderen gehen leer aus.
Auf der Suche nach den Ursachen warf ich einen Blick auf das Raid:
# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 hda3[0] hdb3[1]
192434496 blocks [2/2] [UU]
[=================>…] check = 88.0% (169503744/192434496) finish=422.0min speed=904K/secmd1 : active raid1 hda2[0] hdb2[1]
2931776 blocks [2/2] [UU]md0 : active raid1 hda1[0] hdb1[1]
48829440 blocks [2/2] [UU]
Ein mdadm -D /dev/md2 beruhigt ebenfalls mit der Meldung „State : clean, recovering“ (und ich muss gerade entdecken, dass WordPress aus –detail einen Einzelstrich macht).
Die Ursache ist nun also klar: Am Sonntag war wohl /md0, am Montag /md1 und Teile von /md2 dran – und ich bin inzwischen froh, dass ich nur 250GB Platten im Raid hab. Zuerst dachte ich an einen Fehler – doch dann entdeckte ich, dass dieser Job regelmäßig abläuft.
In /etc/cron.d/mdadm steht wann:
#
# cron.d/mdadm — schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft <madduck@madduck.net>
# distributed under the terms of the Artistic Licence 2.0
#
# $Id: mdadm.cron.d 147 2006-08-30 09:26:11Z madduck $
## By default, run at 01:06 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).
6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray –cron –all –quiet
Seit einem Jahr hab ich das Raid nun schon am Laufen und hab nichts von dieser Funktion gemerkt. Wenn /usr/share/mdadm/checkarray tatsächlich jeden ersten Sonntag im Monat aufgerufen werden muss, dann darf ich a) mein Raid auflösen b) dies auf jeden Sonntag beschränken, der vor dem 3ten eines Monats liegt oder c) den Prozess im Bedarfsfall anhalten mit
/usr/share/mdadm/checkarray -x
Eine –help Option gibt es für checkarray auch. Eine Dokumentation lieg in /usr/share/doc/mdadm/README.checkarray, eine man Page hat weder mein Debian noch mein Ubuntu zu bieten.
Jetzt bin ich zwar was die Geschwindigkeit meines Servers angeht beruhigter, kann aber nicht arbeiten, weil alle Daten ja auf dem Server (und dort in md2) liegen und dieser Prozess so viel Systemressourcen frisst, dass schon der Aufruf von Google scheinbar ewig dauert. Hier rächt sich nun der integrierte IPCop.
Die Schnapsidee, an den Moodleseiten auf dem LFB zu arbeiten quittierte mein DreamWeaver heute Morgen mit einer Wartezeit von 90 Minuten für das Einlesen des Verzeichnisbaums und eine Sicherungskopie von /elearning/moodle vor der notwendigen Restrukturierung läuft nun schon seit 4 Stunden, obwohl das Archiv auf dem Client liegt. Mein Server will wohl, dass ich Urlaub mache.
Die einzige Art, wie ein Software Raid unter der Herrschaft von mdadm auf einem Linux überprüft werden kann, scheint demnach zu sein, die Partitionen zu rsyncen.
Hm?!