Unter Linux programmgesteuert die Beschädigung von Dateien simulieren? (für DB-Haltbarkeitstests)

Grundsätzlich möchte ich, dass fwrite() nBytes und < nBytes auf die eigentliche Festplatte geschrieben werden, oder was auch immer zu anderen Inkonsistenz-Artefakten führen könnte (wenn Sektoren außerhalb der Reihenfolge geschrieben werden).

Ich weiß, ich könnte dies auf Hardwareebene entweder mit:

• blankes Metall durch Ziehen des Netzkabels ODER
• mit einem virtualisierten Betriebssystem, indem einfach ein Reset über den Hypervisor ausgeführt wird.

.. aber ich mag die oben genannten Fälle nicht, weil:

• Ich möchte meine Hardware nicht durch tatsächlichen Stromausfall beschädigen.
• Die tatsächliche Stromausfallsimulation ist manuell und / oder schwer & hässlich zu automatisieren.
• Die Energieverlustsimulation von Virtualisierung ist zwar besser, aber ich denke, es wäre ziemlich langsam, 100 Läufe gegen die Datenbank auszuführen, indem auf VM-Starts gewartet wird.

Ich suche also nach einer schnelleren und einfacheren Lösung für die Automatisierung.

Ich hatte ein paar Ideen:

1) Beenden Sie den Vorgang mit $ kill -9 dbms_pid

Das wird wahrscheinlich nicht funktionieren, da ich schätze, dass alles, was ihm gegeben fwrite()wird, atomisch zu den vom Kernel verwalteten Puffern hinzugefügt wird (dies ist eine Spekulation), und nachdem der Prozess beendet wurde, werden die Puffer normalerweise nur auf die Festplatte gespült.

2) Heben Sie die Bereitstellung des Dateisystems während des Schreibvorgangs auf

Ich glaube nicht, dass das Aufheben der Bereitstellung funktioniert, während sich im Dateisystem offene Dateien befinden.

3) Das Dateisystem muss sich auf einem Loopback-Gerät befinden, das von einer Datei gesichert wird. Stoppen Sie einfach das Schreiben in diese Datei an der Stromunterbrechungsstelle

Ich glaube nicht, dass es dafür einen Mechanismus gibt. Durch das Umbenennen der Datei werden die Schreibvorgänge in das Dateisystem wahrscheinlich nicht angehalten, da der Loopback-Treiber sich wahrscheinlich nur auf einen Inode oder einen internen Verweis bezieht.

Das Aufheben der Bereitstellung des Loopback-Geräts hat wahrscheinlich das gleiche Problem, dass es nicht möglich ist, wenn jemand Dateien geöffnet hat.

Das Kopieren aus der Block-Device-as-a-Datei könnte funktionieren (es sei denn, es ist schreibgeschützt, was wahrscheinlich der Fall ist). Da das Kopieren des Inhalts jedoch keine atomare Operation ist, führt dies wahrscheinlich zu Artefakten, die nicht mit dem Ausschalten zusammenhängen.

4) Heben Sie das Dateisystem auf LVM hoch und machen Sie einen Schnappschuss

Dies ist wahrscheinlich meine praktikabelste Idee. Eine Momentaufnahme des LVM-Volumes zu erstellen, ist atomar und könnte Stromverlust ziemlich simulieren? Ich denke, nicht gelöschte Puffer / Seiten werden für den Snapshot nicht berücksichtigt (was für meine Simulation gut ist), und ich hoffe, ich würde die gleichen Artefakte wie einen Stromausfall einführen, als wäre der fwrite()Inhalt nur halb geschrieben.

Gibt es Out-of-Order-Schreibvorgänge oder werden auf LVM-Volumes geschriebene Seiten immer in der richtigen Reihenfolge angewendet?

Hast du noch andere Ideen? Was denkst du über die Möglichkeiten? Sie stimmen zu, dass 4) die beste Idee ist?

Warum mache ich das: Im Grunde entwickle ich eine Datenbank, deren Haltbarkeit ich gerne testen möchte, indem Sie ein automatisiertes Skript erstellen, das eine umfassende Runde von Folterprüfungen durchführt, indem es Daten zum Speichern gibt und gleichzeitig einen Stromausfall simuliert Zumindest die Festplatte und dann überprüfen, dass keine festgeschriebenen Daten verloren gegangen sind und die Datenbank sicher wiederhergestellt werden kann.