kein Datenverlust trotz Stromausfall

[cosmac]

hi,

ja, man könnte eine USV verwenden, aber das ist ja langweilig Ich meine es geht auch so:

man nehme eine System- und zwei reine Daten-Partitionen und mounte alle erstmal read-only. Soweit sollte das ganze unkaputtbar sein. Schreiben auf die System-Partition ist ein anderes Thema, Daten schreiben geht so:
* Partition A r/w mounten
* schreiben
* Partition A r/o mounten
* Partition B r/w mounten
* die gleichen Daten schreiben
* Partition B r/o mounten

Nach einem Stromausfall zum ungünstigen Zeitpunkt ist entweder Partition A im neuen Zustand und B kaputt oder A ist kaputt und B noch im alten Zustand. Im ersten Fall gibt es keinen Verlust, im zweiten Fall verliert man genau den einen Datensatz, der gerade geschrieben wurde. Das sei mal per Definition kein Problem. In beiden Fällen braucht man nur die gute Partition auf die andere zu kopieren; auch dabei kann nichts schief gehen.

Jetzt die Fragen:
was ist an dem Plan falsch? (mir fällt es einfach nicht ein)
kann ext3/4 das genauso sicher? (kann ich mir nicht vorstellen)

Bonus-Frage: lohnt sich eine zweite Festplatte für B? Auf den ersten Blick natürlich, es hilft sicher gegen den gewöhnlichen Festplatten-Ausfall. Aber kann man sicher sein, dass dann B erst beschrieben wird, wenn A fertig ist? Bei zwei Partitionen auf einer Platte bin ich überzeugt das es so ist. Weil die Spuren weit auseinander liegen, kann auch der Platten-interne Cache nicht mehr stören.

[123456]

Ähm in welchen Zeitintervallen willst du denn das mount/write/unmount Spiel betreiben?

[cosmac]

naja, also für einen Fileserver für 1000 User ist das nicht gedacht. Im wirklichen Leben eines einzelnen Users werden Daten aber nur selten ergänzt oder und noch seltener geändert. Zum Beispiel sollten Desktop-Anwendungen ihre config-Dateien und z.B. Bookmarks so behandeln. Ein Programm das Logfiles schreibt müsste Meldungen intelligent zusammenfassen können und könnte dann alle paar Sekunden auch Bursts von ein paar Meldungen verarbeiten.

Aktuell bastel ich an zwei ganz verschiedenen Anwendungen, die beide sowas brauchen. Im einen Fall verwende ich einen extra Microcontroller mit NOR-Flash für den Zweck. Da könnte man was sparen.

[storm]

was ist an dem Plan falsch? (mir fällt es einfach nicht ein)

Wenn du so fragst, hast du doch schon Zweifel? *g
Als Stichpunkt könnte man an der Stelle delayed allocation anführen, das dir an der Stelle in die Suppe spucken könnte (überhaupt der block device layer). Man könnte das ganze zwar mit sync erzwingen, aber dann wirds noch langsamer. Ob sync in dem Fall überhaupt hilft, kann ich gerade auch nicht sagen.

Bonus-Frage: lohnt sich eine zweite Festplatte für B? Auf den ersten Blick natürlich, es hilft sicher gegen den gewöhnlichen Festplatten-Ausfall. Aber kann man sicher sein, dass dann B erst beschrieben wird, wenn A fertig ist? Bei zwei Partitionen auf einer Platte bin ich überzeugt das es so ist. Weil die Spuren weit auseinander liegen, kann auch der Platten-interne Cache nicht mehr stören.

Für das sequentielle Verhalten spielt das imo keine Rolle: wenn du die zeitlich getrennte Ausführung der Schreibbefehle richtig implementierst, sollte es egal sein, ob du 1 oder 2 Platten verwendest.

ciao, storm

[123456]

dann empfehle ich Windows, das knippst du aus und es kommt ohne Probleme wieder hoch. das haben irgendwelche TV EDV Fritzen mal ausgetestet nachdem die Frage kam "kann man Windows einfach per Austaste abschalten" - verblüffend stabil.

Spass beiseite. Mir fehlt zwar den Sinn für solche komplizierten Übungen (da ich es gerne einfach, übersichtlich und stabil halte) und da würde ich eine USV vorziehen, bei einem simplen Desktop wahrscheinlich gar nichts machen, aber anscheinend brauchst du das für irgendwelche Anwendungen.

Mit wenigen überschaubaren Anwendungen kann ich mir das vorstellen.
Ansonsten müsstest du wissen welche Prozesse des OS und der Anwendungen alle Daten schreiben - und dann auch wann die das tun. Dann müsstest du das irgendwie synchronisieren, d.h. die Prozesse irgendwie abfangen damit nicht beliebig alle Millisekunden geschrieben wird. Das klingt nach einiger Arbeit. Die Belastung der HD und die Lebensdauer wird auch leiden. Den Performanceverlust solltest du auch mal andenken.

ps: irgendwie klinge ich wie die contra Position zu dem Projekt.

[cosmac]

was ist an dem Plan falsch? (mir fällt es einfach nicht ein)

Wenn du so fragst, hast du doch schon Zweifel? *g

na klar, es sieht einfach zu einfach aus

Als Stichpunkt könnte man an der Stelle delayed allocation anführen, das dir an der Stelle in die Suppe spucken könnte (überhaupt der block device layer).

deswegen ja der Aufwand mit "umount"; danach sollte wirklich jeder Block allocated und weg geschrieben sein. Das dürfte sogar sicherer sein, als direkt auf das rohe Device zu schreiben (also ohne Dateisystem).

Für das sequentielle Verhalten spielt das imo keine Rolle: wenn du die zeitlich getrennte Ausführung der Schreibbefehle richtig implementierst, sollte es egal sein, ob du 1 oder 2 Platten verwendest.

jetzt wo du's sagst, sehe ich eigentlich auch keinen Unterschied mehr. Allerdings kann ein defektes Netzteil auch 2 Platten gleichzeitig schrotten.

dann empfehle ich Windows, das knippst du aus und es kommt ohne Probleme wieder hoch.

Dafür vergisst es schon mal was, wenn man es sauber runter fährt

Mir fehlt zwar den Sinn für solche komplizierten Übungen (da ich es gerne einfach, übersichtlich und stabil halte) und da würde ich eine USV vorziehen

Ich finde es fast zu einfach. Ich würde diese zwei Spezial-Partitionen nämlich für eine bestimmte Anwendung reservieren. Alles andere kann ganz normal weiter laufen oder ausgewählte Programme können in ein tmpfs schreiben; das lässt sich regeln. Entweder man nimmt das Risiko einer kaputten System-Partition in Kauf oder man mountet sie auch read-only. Die Daten sind meistens wertvoller.

Die Belastung der HD und die Lebensdauer wird auch leiden.

Opfer müssen gebracht werden. Wenn die Schreibvorgänge länger auseinander liegen als das flush-Intervall des Systems (davon gehe ich aus), dürfte es aber kaum einen Unterschied machen.

Den Performanceverlust solltest du auch mal andenken.

man wird sehen, vielleicht merkt es keiner

ps: irgendwie klinge ich wie die contra Position zu dem Projekt.

das ist ja dein Job hier, danke dafür!

[storm]

Ich hab noch etwas an dem Thema herumgekaut. Aus performance-Sicht ist das Verfahren sehr 'teuer'. In einer stark vereinfachenden Rechnung würde es doch so aussehen: für eine angenommene Zahl n von zu schreibenden Blöcken gibt es die normale Variante des Schreibens

Code: Alles auswählen

 mount(); n x write(); umount() 

mach zusammen O(n) = 1+ n + 1 = n; für deine Variante des sicheren Schreibens

Code: Alles auswählen

 n x { mount(); write_a(); umount(); mount(); write_b(); umount() } 

macht zusammen O(n) = 6n, also ein 6-facher overhead für das Verfahren. Solange du nur in kB-Häppchen schreibst, ist das vielleicht zu verkraften, aber bei größeren Datenmengen wird es sicherlich unappetitlich. Und wirklich sicher gegen Datenverlust bist du ja immer noch nicht. Da ist vielleicht die USV oder eine batteriegepufferte raid-lösung (im spiegelnden Modus) die bessere Variante. :)

ciao, storm

[123456]

mir schiesst da auch noch ein Gedanke durch den Kopf... Das einzige Problem, das du mit einigem Aufwand löst ist der Case wenn mal der Strom ausfällt.

Ich kann mich an USV's in Firmen erinnern die schimmelten vor sich hin und haben es schlicht nicht mehr getan, weil die keiner überprüft hat und das lag - tätääh - daran das ein Stromausfall so selten vorkommt zumindest in unserem geordneten Deutschland.

Wie viele Stromausfälle hast du denn statistisch in der Umgebung die du betrachtest?

[Danielx]

kann ext3/4 das genauso sicher?

Das kommt darauf an, welche Journaling-Stufe man verwendet.
Ich zitiere mal eben aus Wikipedia:

Die Linux-Implementierung von ext3 bietet drei Journaling-Stufen:

• Full (Option data=journal), wobei sowohl Metadaten als auch Dateiinhalte erst ins Journal geschrieben werden, bevor sie ins Dateisystem geschrieben werden. Dies erhöht die Zuverlässigkeit, ist jedoch recht langsam beim Schreiben, da alle Daten zweimal auf den Datenträger geschrieben werden müssen. Lesevorgänge werden beschleunigt.
• Writeback (Option data=writeback), wobei nur Metadaten ins Journal geschrieben werden. Das Aktualisieren der Dateiinhalte wird dem normalen sync-Prozess überlassen. Dies ist wesentlich schneller, birgt jedoch die Gefahr von Datenverlust durch abgebrochene Out-of-Order-Schreibvorgänge im Absturzfall. Dateien, die sich zu diesem Zeitpunkt im Schreibzugriff befanden, können beim nächsten Einhängen des Dateisystems an ihrem Ende Datenmüll enthalten.
• Ordered (Option data=ordered) funktioniert wie Writeback. Allerdings werden Dateiinhalte direkt ins Dateisystem geschrieben, erst danach werden die Metadaten im Journal aktualisiert. Dies gilt als akzeptabler Kompromiss zwischen Zuverlässigkeit und Geschwindigkeit und ist daher die Standardeinstellung.

Quelle: http://de.wikipedia.org/wiki/Ext3

Hervorhebungen von mir hinzugefügt.

Und im Zweifel dann noch den Write-Cache der Festplatte abschalten.

Gruß,
Daniel

[GregorS]

Hallo!

Als jemand, der zwei USVs besitzt, kann ich meine Finger nicht von der Tastatur lassen.

Das mit dem Datenverlust bei Stromausfall ist ja schon ein gutes Argument für die Beschäftigung mit der Frage, ob USV oder nicht oder doch oder so. Ich habe mir meine USVs allerdings aus einem anderen Grund angeschafft – und da hilft selbst die beste Software nicht: Ich habe einmal erleben dürfen, was in Sekundenbruchteilen dahingerafft werden kann, wenn ein Blitz in der näheren Umgebung einschlägt. Und weil ich das nicht noch einmal erleben wollte, vor allem nicht mit meiner EDV, habe ich in den sauren Apfel gebissen und mir diese Kästchen eben angeschafft. M. E. der beste Schutz gegen jegliche Störung im Stromnetz.

Gruß

Gregor

[Danielx]

M. E. der beste Schutz gegen jegliche Störung im Stromnetz.

Eine USV selbst schützt doch aber erstmal nicht vor Blitzschäden, solange diese selbst am Stromnetz hängt, oder?
Und wie schützt du dich vor Schäden über die Internetanbindung?
Verwendest du anstatt Kabel eine Funkverbindung?

Gruß,
Daniel

[GregorS]

M. E. der beste Schutz gegen jegliche Störung im Stromnetz.

Eine USV selbst schützt doch aber erstmal nicht vor Blitzschäden, solange diese selbst am Stromnetz hängt, oder?
Und wie schützt du dich vor Schäden über die Internetanbindung?
Verwendest du anstatt Kabel eine Funkverbindung?

Hallo Daniel,

ob eine USV tatsächlich vor Blitzschäden schützt, weiß ich wahrscheinlich erst dann endgültig, wenn in meiner Nachbarschaft einer einschlägt. Ich lege für den Blitzschutz meiner USVs keine Hand ins Feuer. Ich bin mir einfach nur "sehr sicher".

Was Schäden über die Netzanbindung angeht: Eine meiner USVs hat auch hierfür Anschlüsse. Da wird die Verbindung vom Router zu meinem kleinen Netz durchgeschleift. Aber auch hier gilt: Momentan glaube ich einfach nur daran, dass das schützt. Wissen werde ich’s erst, wenn’s funktioniert hat (oder nicht). Wer hierzu mit Erfahrungen dienen kann, möge das tun!

Gruß

Gregor

[Danielx]

Es gibt durchaus USVen mit eingebautem Überspannungsschutz, allerdings kosten diese deutlich mehr, zumindest wenn man einen wirksamen Schutz haben möchte.

Gruß,
Daniel