Danke für die vielen Tips.

Hast Du denn schon mal in der o.g. Tabelle nachgeschaut, ob Deine Hardware es überhaupt können soll?

Ich kann Dir mit den o.g. Informationen nur einen Fingerzeig geben in welche Richtung Du recherchieren und bugtracken kannst. Ich wünsche Dir dabei viel Erfolg. Wenn Du etwas allg. gültiges herausgefunden hast, würde ich mich über einen Kommentar auf dieser Seite freuen, so dass ggf. auch andere Hilfesuchende den richtigen Fingerzeig bekommen können.

Die erste Zeile Deines Syslogs (“mdadm: SpareActive event detected on md device”) sagt laut man page aus: SpareActive = A spare component device which was being rebuilt to replace a faulty device as been successfully rebuild and has been made active.

Dieser Event passt eigentlich nicht so recht in Dein Szenario wo Du das SATA Kabel ziehst. Du siehst – es ist für mich quasi unmöglich mit den wenigen Infos konkret helfen zu können.

Danach wirft der Kernel diese ATA Fehler aus. Hierzu musst Du mal Google bemühen oder in einen spezialisierten Forum eine Anfrage starten. Tut mir leid, dass ich Dir hier nicht weiterhelfen kann.

Zu Deiner zweiten Frage:
“The old /etc/raidtab is completely ignored by the new mdadm package”…
Quelle: http://lwn.net/Articles/139887/

http://www.we-provide.de/syslog1.JPG

“Der Serial-ATA-Bus ist von Haus aus Hotplug-fähig. Wer aber glaubt, dass jeder SATA-Controller diese Eigenschaft erbt und man im laufenden Betrieb Platten entfernen und einstecken darf, hat weit gefehlt.” … “Denn natürlich liegt es im Interesse eines jeden Administrators, ausgefallene Platten schnell im laufenden Betrieb wechseln zu können, um die Verfügbarkeit hoch zu halten. Doch um es gleich vorweg zu sagen: Die Sache ist so einfach nicht, der Teufel steckt wie immer im Detail, und zwar im Treiber.” … “Um ein internes, Hotplug-fähiges Raid aufzubauen, ist zunächst einiges an Recherche nötig. Dieser Artikel fasst die Ergebnisse einer solchen zusammen.”

Ich denke der Artikel dürfte zum Verständnis Deiner Probleme führen.

Dieser Tabelle:

kannst Du entnehmen, was mit Deiner Hardware möglich ist.

Im ersten Teil meines Blogs schreibe ich ja auch recht ausführlich was in meinem konkreten Fall zu tun war um das Optimum aus der bei mir vorhandenen Hardware herauszuholen. In meinem Fall wird ja AHCI mit HotPlug explizit verwendet, so das ich einen Plattenausfall durch das Entfernen des SATA Kabels problemlos testen kann und ein evtl. wirklich ausgefallenes Laufwerk im laufenden Betrieb austauschen kann. Echts HotPlug ist hier also möglich – aber nicht jedes SATA Setup kann das…

Und nicht entmutigen lassen. In dem referenzierten Artikel heißt es so schön:

“Ein internes Hotplug-fähiges SATA-Raid aufsetzen erfordert, die Hardware klug auszuwählen und die neueste Software einzusetzen. Die letzte Forderung visiert zudem ein bewegliches Ziel an. Seit längerem ändert sich von einer Kernelversion zur nächsten viel an den SATA-Treibern – in der Regel sind es Verbesserungen. Da heißt es auch für Admins, denen das Kunststück gelungen ist, ein Raid in Betrieb zu nehmen, stets am Ball zu bleiben – die in diesem Artikel genannten Links werden zum großen Teil liebevoll gepflegt. Als Lohn der Mühe winken Performance-Verbesserungen oder eine neue Teilfunktionalität.”

MfG Jonas

PS: Habe den Server gerade nicht hier, kann es also jetzt nicht ausprobiern, deswegen vorab die Frage.

Schaue doch mal in Dein /var/log/syslog ob Du dort weitere Hinweise für das Verhalten findest.

Bei mir läuft das System seit Monaten Stabil. Die einzige Auffälligkeit über die ich mal gestolpert bin sind regelmäßige Einträge im syslog:

Sep 2 01:06:02 aurora mdadm: RebuildStarted event detected on md device /dev/md0
Sep 2 01:38:02 aurora mdadm: Rebuild20 event detected on md device /dev/md0
Sep 2 02:11:02 aurora mdadm: Rebuild40 event detected on md device /dev/md0
Sep 2 02:44:02 aurora mdadm: Rebuild60 event detected on md device /dev/md0
Sep 2 03:22:01 aurora mdadm: Rebuild80 event detected on md device /dev/md0
Sep 2 04:18:57 aurora mdadm: RebuildFinished event detected on md device /dev/md0

Ein manueller Rebuild wurde nicht in Auftrag gegeben. Die Ursache kommt aus /etc/cron.d/mdadm:

#
# cron.d/mdadm — schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft
# 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

Warum nun jedoch der periodic redundancy check wie ein rebuild ausgewiesen wird, beschäftigt auch andere Blogger. Conclusion:

“check’ is a read-only operation, even though the kernel logs may suggest otherwise (e.g. /proc/mdstat and several kernel messages will mention “resync”).”

und

“In short: it’s a bug. checkarray is actually not a resync, but the kernel does not distinguish between them.”

vielen Dank für das Tut, echt nett gemacht. Vorallem der Link “”Install Debian Etch on a Software Raid 1 with S-ATA disks”:” war sehr hilfreich. Nun, ich habe eine Frage, ich habe auch ein Raid 1 laufen wird auch korrekt von mdadm –detail /dev/md0 angezeigt, leider hatte ich bei dem Festplatten ausfall einen Fehler, bzw. es lief glaub ich nicht so wie es sein sollte:

Als ich das SATA Kabel einer Festplatte entfernte lief das System instabil, ich konnte mich mit dem Server zwar per Putty noch verbinden aber konnte kaum noch was machen, auch mit Samba konnte ich mich nicht mehr verbinden.

Woran kann das liegen?

PS: Wenn ich den Server herunterfahre ein Kabel entferne erkennt er es und startet von der funktionierenden Platte.