Ich habe auf einem meiner Geräte eine TinyCore-Linux-Distribution (3.6), die Disk-on-Module- oder Compact-Flash-Speicher verwendet.
Das Dateisystem ist ext2.
Ich habe einen LAMP-Stack auf diesem Gerät und spiele mit einer MySQL-Datenbank mit über 400 Tabellen (myisam). Schreibvorgänge erfolgen systematisch alle 15 Minuten.
Diese Tabellen werden von meiner Webanwendung entsprechend meinen Setup-Anforderungen generiert.
Nun kommt es vor, dass dieses Gerät aufgrund von Strommangel abrupt abgeschaltet wird.
Folgendes passiert: Wenn MySQL einen Schreibvorgang ausführt (z. B. update, delete, insert), können einige Daten und Indexdateien beschädigt werden.
Es ist sicher keine große Sache, aber die Durchführung einer repair tableOperation ist nicht so schlimm; Tabellen werden repariert und Anwendungen können weiter ausgeführt werden, auch wenn leider einige Daten verloren gehen (was in meinem Fall akzeptabel sein könnte).
Das Problem besteht darin, dass bei einem plötzlichen Herunterfahren häufig mehrere MySQL-Tabellendateien (FRM oder MYI oder MYD) den Status „Eingabe-/Ausgabefehler“ aufweisen und mein MySQL-Frontend für diese Tabellen einen „Speicher-Engine-Fehler 5“ (E/A-Fehler) meldet. Anwendungen, die die Datenbank verwenden, können offensichtlich nicht ordnungsgemäß ausgeführt werden.
Anstatt Ereignisse wie diese zu verhindern (die meiner Meinung nach bis zu einem gewissen Grad unvermeidbar sind), möchte ich über eine Möglichkeit nachdenken, Datei-E/A-Fehlersituationen, die sich aus den oben beschriebenen Szenarien ergeben, korrekt und möglicherweise automatisch zu beheben.
Irgendwelche Ideen?
BEARBEITEN: Leider kann ich nicht auf ext3 umsteigen, ich muss bei ext2 bleiben, auch aus dem Grund, dass ext3 die Schreibzyklen des Solid-State-Speichers stark beeinträchtigen würde.
Antwort1
Ich denke, wenn Sie CF verwenden, ohne die Möglichkeit zu verwendenDM-MultiPathoder andere Funktionen für höhere Verfügbarkeit, dann sollten Sie diese Dateisysteme zumindest mit der Option „noatime“ mounten, um die Lebensdauer zu verlängern (indem Sie sich für Ihre eigenen Skripte usw. nicht auf Atimes verlassen).
Abgesehen davon klingt es nicht nach der robustesten Plattform.