Schutz von BeagleBone Black vor eMMC-Korruption bei Stromausfall

Ich denke über eine Anwendung nach, bei der ein BeagleBone Black, vorzugsweise mit einem der empfohlenen, in eMMC geladenen Debian-Images , von einer 5-V-Quelle gespeist wird, die jederzeit entfernt werden kann. Ich möchte in diesem Fall einen katastrophalen Datenverlust verhindern, auch wenn gerade in eine Datei geschrieben wird. Zumindest möchte ich, dass die BBB bei Rückkehr der Stromversorgung immer noch von eMMC neu starten, das (wahrscheinlich ext4) Dateisystem reparieren und meine Anwendung ausführen kann. Wenn ich die Gewissheit haben kann, dass jede Datei, die ordnungsgemäß geleert wurde, konsistent ist, ist das ideal.

Das Problem, das ich befürchte, ist, dass es bei einem Stromausfall während eines Schreibvorgangs im eMMC zu Datenverlusten in einem unvorhersehbaren Sektor kommen könnte, da ein kürzlich vom eMMC verarbeiteter Sektorschreibvorgang eine Flash-Seitenlöschung und die anderen Sektoren ausgelöst hat diese Seite gehen verloren, und sie gehören (aufgrund des Verschleißausgleichs und der Neuzuordnung von Sektoren innerhalb des eMMC) zu Dateien oder Datenträgern, die kürzlich nicht geschrieben wurden, einschließlich möglicherweise in schreibgeschützten Dateisystemen oder Dateien. Dieses Problem wird hier erwähnt :

Ein Aus- und Wiedereinschalten zum falschen Zeitpunkt kann Daten überall auf der (SD- oder eMMC-)Karte zerstören, egal wo Sie schreiben

und das könnte die Warnung im BBB-Handbuch und hier das rechtfertigen

[Herunterfahren mit dem Netzschalter] hilft auch dabei, eine Kontamination der SD-Karte oder des eMMC zu verhindern.

ebenso wie die knappe Warnung von der scheinbar primären eMMC-Quelle für die BBB

Vermeiden Sie eine Abschaltung während WRITE- und ERASE-Operationen.

Inwieweit kann ein solcher Datenverlust auftreten? Wie lange dauert das Schwachstellenfenster, falls vorhanden?

Gibt es Standardlösungen? Empfehlungen?

Gibt es einen eingebauten Softwaremechanismus dagegen, und wie funktioniert er? Ist der TPS65217C PMIC speziell so programmiert, dass er bei Verlust von VDD_5V, auch bekannt als AC, ein NMI generiert, wie es die Hardware zulässt, und wird es so gehandhabt, dass die laufende eMMC-Schreibaktivität gestoppt wird? Wenn nicht, wie kann ich das wenigstens hinzufügen?

Ist das Stoppen jeglicher eMMC-bezogenen Aktivitäten gut genug, damit das eMMC nach einer gewissen Verzögerung von selbst in einen sicheren Zustand übergeht? Welche Verzögerung?

Was ist mit einem Kondensator oder Supercap (wie Murata DMT3N4R2U224M3DTA0: 0,22 F, 4,2 V, 0,3 Ω) am Batterieanschluss, um eine gewisse Leistungsreserve bereitzustellen?

Gibt es Modi/Einstellungen in der eMMC, um eine Kompromittierung der Schreibleistung/Sicherheit zu konfigurieren? Was sind die Standardeinstellungen, sind sie einstellbar?

Wichtiges Update: Ich habe maßgebliche Informationen in der eMMC-Spezifikation vom März 2010 zur Zuverlässigkeit bei Stromausfall während des Schreibens gefunden :

Im Allgemeinen sollte eine Unterbrechung eines Schreibvorgangs keine Beschädigung vorhandener Daten an irgendeiner anderen Adresse verursachen. Das Risiko, dass während eines Schreibvorgangs die Stromversorgung unterbrochen wird, ist jedoch in verschiedenen Anwendungen unterschiedlich. Außerdem gibt es bei einigen Technologien, die zum Implementieren von eMMC verwendet werden, einen Kompromiss zwischen dem Schützen vorhandener Daten (z. B. Daten, die durch die zuvor abgeschlossenen Schreiboperationen geschrieben wurden) während eines Stromausfalls und der Schreibleistung.

In dieser Quelle folgen viele wertvolle Informationen, einschließlich einer Beschreibung, wie das eMMC erklärt, dass es verspricht (oder nicht), zuvor geschriebene Daten im Falle eines Stromausfalls vor zufälliger Löschung zu schützen, und was wirklich schreibgeschützte Bereiche zu sein scheinen.

Ergänzung: In einem Kommentar wird erwähnt, dass Mobiltelefone schreibgeschützte Dateisysteme in eMMC verwenden, und es ist nicht bekannt, dass diese beschädigt werden. Mobiltelefone haben jedoch einen großen Akku, und das stellt praktisch sicher, dass sie im normalen Betrieb keinen plötzlichen Stromausfall erleiden, und sind daher nicht von dem eMMC-Korruptionsmechanismus betroffen, den ich befürchte.

Zumindest sollten Sie System und Daten auf unterschiedlichen Dateisystemen aufbewahren (wie es Android tut). Das System sollte RO montiert werden.
Das ist eine interessante Frage. Ich bin mir jedoch nicht sicher, ob jemand eine bereits getestete und garantierte Lösung finden kann. Ich fürchte, Sie müssen sich das selbst ausdenken ... Wenn ja, posten Sie bitte eine Antwort auf Ihre eigene Frage ...
@Sean Houlihane: Ich sehe keinen Grund, warum die Verwendung eines bestimmten schreibgeschützten Dateisystems sicherstellen würde, dass ein zu diesem Dateisystem gehörender Block durch den von mir beschriebenen Mechanismus nicht verloren gehen kann. Ich bin nicht einmal in der Lage zu rechtfertigen, dass dies die Wahrscheinlichkeit eines solchen Verlusts erheblich verringern würde (mangels eines Modells, wie das eMMC logische Blöcke besser als "zufällig" auf Flash-Seiten abbildet). Wenn Sie eine Begründung oder Erfahrung haben, die rechtfertigt, dass ein schreibgeschütztes Dateisystem die Wahrscheinlichkeit, beschädigt zu werden, erheblich verringert hat, geben Sie bitte eine Antwort zu diesem interessanten Punkt.
Fragen Sie am besten Google nach der Begründung. Soweit es mich betrifft, ist dies gängige Praxis, und das seit Jahren. Telefone verwenden normalerweise eine einzelne eMMC mit mehreren Partitionen für Booten, Notbooten, System und Benutzerdaten. Ich habe noch nie von einem Telefon gehört, das mit dieser von Ihnen beschriebenen Methode aufgrund von FS-Korruption hart gemauert wurde.

Antworten (3)

Hier müssen alle Schichten des Stapels zusammenarbeiten.

Das eMMC-Speichergerät verfügt über einen integrierten Load-Balancer, der mit Stromausfallsituationen elegant umgehen muss. Ich würde erwarten, dass es das tut, indem es vorgibt, dass unvollständig geschriebene Blöcke überhaupt nicht geschrieben wurden.

Das Dateisystem muss Stromverluste zwischen Blockschreibvorgängen bewältigen können. Die Dateisysteme ext3und erfüllen dies, da sie protokolliert werden und die Reihenfolge der Schreibvorgänge erzwingen, sodass die Journalzugriffe von den tatsächlichen Änderungen des Dateisystems getrennt bleiben.ext4

Der Schwachpunkt in Ihrem Setup ist der Paketmanager, der keine gute Lösung bietet, wenn während eines Paket-Upgrades der Strom ausfällt. Normalerweise sollten Sie immer noch booten können, es sei denn, der Fehler ist genau während des Umbenennens von Dateien nach einer Installation aufgetreten, und die umbenannten Dateien waren wichtige Systemdateien.

Für fast alle Zwecke ist dieses Fenster so klein, dass Sie das Problem ignorieren können. dpkg --configure -aSie können es weiter verkleinern, indem Sie und während jedes Bootens ausführen dpkg -iGROEB /var/cache/apt/archives- diese sollten Sie nach einem unterbrochenen Update auf Kosten einiger Zeit wieder in einen gesunden Zustand versetzen, und sie können keine Fälle behandeln, in denen dpkg selbst oder das Init-System beschädigt wurden infolge.

Zu guter Letzt können Sie in einer Initrd ein Rettungssystem einrichten, das das System überprüft und versucht, es zu reparieren und/oder bei Bedarf neu zu installieren, und dies im Bootloader verankern.

Haben Sie etwas Beruhigendes, dass der eMMC beim Ausschalten während eines Schreib- oder (internen) Löschvorgangs "vorgibt, dass unvollständig geschriebene Blöcke überhaupt nicht geschrieben wurden" , anstatt "Daten irgendwo zu zerstören" ? Das Beste, was ich dazu habe, ist, dass WR_REL_SET "auf 1Fh gesetzt werden kann, um den Schutz für zuvor geschriebene Daten zu aktivieren, wenn während eines WRITE-Vorgangs ein Stromausfall auftritt", aber diese Versicherung ist ziemlich vage und nicht vom Lieferanten des tatsächlich verwendeten eMMC; die im Gegenteil besagt: "Vermeiden Sie das Herunterfahren während WRITE- und ERASE-Operationen" ; etwas, das eine Gangreserve erfordert.
Intern werden die Daten als Aktualisierungsdatensatz in einen neuen Block geschrieben, um zu vermeiden, dass derselbe Flash-Block mehrmals überschrieben wird, und der neu geschriebene Block hat eine Prüfsumme und Bits, die "zuletzt geschrieben" werden, sodass unterbrochene Schreibvorgänge erkannt und aktualisiert werden können Datensätze nach Neustart ignoriert.

schematisch

Simulieren Sie diese Schaltung – Mit CircuitLab erstellter Schaltplan

Um die Eingangsspannung zu vergleichen und etwas zu tun, bis die Kappe noch geladen ist

Ich verstehe die Idee (obwohl dieser Schaltplan nicht so funktioniert wie er ist; die Ausgabe ist immer hoch). Auf dem BeagleBone Black gibt es ein PMIC, das dies integriert und anscheinend die Fähigkeit hat , ein NMI zu generieren, das zum Sichern von Daten und zum Schlafen verwendet werden könnte . Aber Linux und eMMC sind komplexe Bestien; Ich weiß nicht einmal, wie viel Zeit der eMMC braucht, um den letzten Schreibvorgang sicher abzuschließen!
@fgrieu Es war nur eine Idee, ich schaue mir nur TPS65217C an. Der gesamte Kernel sollte gepatcht werden, um den eigentlichen Schreibvorgang in eMMC zu beenden und dann zu schlafen, aber auch, wenn er aufwacht. Ein NMI ist zum Aufwecken (IMO) nützlicher als das Signal eines Versorgungsausfalls - dies kann bei jedem Scan abgefragt und die Aktion geändert werden, z. B. einige Peripheriegeräte deaktivieren und warten, bis der Schreibvorgang abgeschlossen ist.

Wenn Sie Ihren Beagle Bone über eine Wechselstromversorgung mit Strom versorgen, die Sie steuern können, können Sie den nicht geglätteten, gleichgerichteten Wechselstrom mit einer kleinen Timer-Kappe an einen der GPIOs anschließen. Wenn der Strom ausfällt, haben Sie genügend Zeit, um einen fsyncoder vielleicht sogar einen Kernel-Halt oder, wenn nichts anderes funktioniert, eine Kernel-Panik auszurufen. Alles, um eine Stromunterbrechung während eMMC-Schreib-/Löschzyklen zu verhindern; Jede reine Softwareunterbrechung wird vom Dateisystemjournal behandelt.

Ich suche diese Methode für ein Projekt, an dem ich arbeite.

Schutz von BeagleBone Black vor eMMC-Korruption bei Stromausfall
AntwortenHierDatenschutz-Bestimmungen1y, 0v