Verhindern Sie eine Datenbeschädigung auf dem ext4 / Linux-Laufwerk bei Stromausfall

Ich habe einige eingebettete Boards, auf denen American Megatrends BIOS mit Embedded Linux als Betriebssystem ausgeführt wird. Das Problem, das ich habe, ist, dass die industriellen Flash-Ideen durch Stromausfall beschädigt werden. Ich habe sie als ext4 formatiert. In jedem Fall kann ich den Flash normalerweise mit fsck reparieren, dies ist jedoch in unseren Bereitstellungen nicht möglich. Ich habe gehört, dass das Deaktivieren des Schreib-Caching helfen sollte, aber ich kann nicht herausfinden, wie es geht. Gibt es noch etwas, was ich tun sollte?

Mehr Info

Das Laufwerk ist ein 4-GB-Flash-Modul. Ich habe eine Partition, die ext4 ist. Das Betriebssystem ist auf dieser Partition installiert und grub ist mein Bootloader.

fdisk -l zeigt / dev / sda als mein Flash-Modul mit / dev / sda1 als meine primäre Partition.

Nach einem Stromausfall kann ich es normalerweise nicht vollständig durch die Boot-Init-Skripte schaffen.

Wenn ich das Laufwerk auf einem anderen PC einbinde, führe ich fsck / dev / sda1 aus. Es werden immer Nachrichten wie angezeigt

"zero datetime on node 1553 ... fix (y)?"

Ich repariere sie und es bootet gut bis zum nächsten Stromausfall.

Wenn ich morgen im Büro bin, werde ich die tatsächliche Ausgabe von fdisk -l veröffentlichen

Das ist alles, was ich über die Funktionsweise des Systems weiß. Ich bin kein Systemtechniker, sondern ein Software-Ingenieur, der die Angewohnheit hat, in Schwierigkeiten zu geraten, die außerhalb seiner Berufsbeschreibung liegen. Ich weiß, wie man Laufwerke formatiert, einen Bootloader installiert, Software schreibt und ein Betriebssystem hackt.

Hier ist die Ausgabe von dumpe2fs

#sudo dumpe2fs /dev/sda1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   VideoServer
Last mounted on:          /
Filesystem UUID:          9cba62b0-8038-4913-be30-8eb211b23d78
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              245760
Block count:              977949
Reserved block count:     48896
Free blocks:              158584
Free inodes:              102920
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      239
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Feb  4 15:12:00 2011
Last mount time:          Sun Oct  2 23:48:37 2011
Last write time:          Mon Oct  3 16:34:01 2011
Mount count:              2
Maximum mount count:      26
Last checked:             Tue Oct  4 07:44:50 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Apr  1 07:44:50 2012
Lifetime writes:          21 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      249d2b79-1e20-49a3-b324-6cb631294a63
Journal backup:           inode blocks

Der Schreibcache hat normalerweise nichts mit dem BIOS zu tun. Meistens gibt es dort keine Möglichkeit, die Einstellungen für den Festplatten-Cache zu ändern. Unter Linux sollte die Verwendung hdparm -W 0helfen.

Die Einstellung ist dauerhaft. Wenn Sie also in Ihren Produktionssystemen kein HDPAR-System zum Herumspielen haben, sollten Sie in der Lage sein, den Schreibcache für Festplatten auf einem anderen System zu deaktivieren und die Festplatte erneut anzuschließen.

Übrigens: Ich würde die Idee eines nicht beschreibbaren Root-Dateisystems unterstützen (Ihr System könnte also in einer Art "Wiederherstellungsmodus" booten und Remotezugriff ermöglichen, selbst wenn das beschreibbare Dateisystem aus irgendeinem Grund nicht bereitstellbar ist). Wenn Sie das Hardware-Design ändern können, sollten Sie MTD-Geräte anstelle von IDE / SATA-Festplatten mit einem Flash-fähigen Dateisystem wie jffs2 verwenden . Wir verwenden diese Kombination seit mehreren Jahren mit mehreren eingebetteten Geräten (hauptsächlich VPN-Router-Lösungen im Feld) mit guten Ergebnissen.

Update: Die Wurzel Ihres Problems scheint zu sein, dass Sie ein ext4-Dateisystem mit deaktiviertem Journal ausführen - has_journalfehlt in der Filesystem featuresListe. lsof +f -- /Fahren Sie einfach alle Dienste herunter, überprüfen Sie, ob noch Dateien geöffnet sind , stellen Sie Ihre Root-Partition mit schreibgeschützt erneut bereit mount -o remount,ro /, aktivieren Sie das Journal mit tune2fs -O has_journal /dev/sda1und richten Sie den "bestellten" Journalmodus als Standard-Mount-Option mit ein tune2fs -o journal_data_ordered /dev/sda1- Sie müssen erneut Führen Sie fsck (vorzugsweise von einem Rettungssystem aus) aus und stellen Sie root / reboot nach diesem Vorgang erneut bereit.

Mit diesen Einstellungen können die Metadaten auch bei einem plötzlichen Stromausfall garantiert aus dem Journal wiederhergestellt werden. Die tatsächlichen Daten werden auch konsistent auf die Festplatte geschrieben, obwohl möglicherweise Daten einige Sekunden vor dem Stromausfall beim Booten angezeigt werden. Wenn dies nicht akzeptabel ist, können Sie die tune2fs -o journal_data /dev/sda1Mount-Option für Ihr Dateisystem verwenden. Dies würde alle Daten einschließen, die im Journal auf die Festplatte geschrieben wurden. Dies würde Ihnen natürlich eine bessere Datenkonsistenz bieten, jedoch auf Kosten einer Leistungsminderung und eines höheren Verschleißniveaus auf Ihrer SSD.

Der Vorschlag für einen Schreibcache ist ein guter Anfang, aber dies klingt nach einem architektonischen Konstruktionsfehler. Auf einem eingebetteten System sollte der interne Flash wahrscheinlich nur in seltenen Fällen R / W montiert werden. Sie sollten wirklich den größten Teil der Arbeit in einem Speicherdateisystem erledigen und Änderungen nach einem Benutzerbefehl oder einem regelmäßigen Intervall wieder mit dem RW-Flash synchronisieren. Es ist wirklich ungewöhnlich, dass ein eingebettetes System während des normalen Betriebs ein reguläres Dateisystem (wie ext4) im rw-Modus verwendet. Wenn es eine Anwendungsanforderung gibt, bei der Sie viel Speicherplatz benötigen, sollten Sie in Betracht ziehen, Ihre Systempartition anders zu gestalten und so zu gestalten, dass die Datenpartition als Teil des Startvorgangs fsck -y'ed werden kann.

Wenn Sie einige Ausgangspunkte benötigen, würde ich mir ansehen, wie Leute plattenlose Linux-Systeme einrichten:

http://frank.harvard.edu/~coldwell/diskless/

und von dort aus starten. Die allgemeine Idee ist, dass Ihre System-Binärdateien und -Daten schreibgeschützt bereitgestellt werden können, damit Ihr Dateisystem nicht beschädigt wird. Sie müssen jedoch in der Lage sein, in bestimmte Bereiche zu schreiben, sodass Sie normalerweise etwas benötigen, um das Dateisystem / tmp, / var / tmp zu speichern. Selbst wenn bestimmte Dinge beschreibbar sein müssen, erstellen Sie einfach ein Skript, um die Partition als r + w zu mounten, und übernehmen Sie die Änderungen. Kehren Sie dann zu schreibgeschützt zurück.

Ein wirklich gutes Beispiel dafür ist die Cyclades-Hardware, das eingebettete Linux. Wenn Sie Konfigurationsänderungen vornehmen, müssen Sie ein Speicherskript ausführen, das die Konfigurationen tatsächlich neu bündelt und in den Flash schreibt.