Wie kann man sicherstellen, dass alle Daten physisch auf die Festplatte geschrieben wurden?

Question

Ich weiß, dass die Flush-Methode von .NET FileStream nur den aktuellen Puffer auf die Festplatte schreibt, aber abhängig vom Windows-Festplattentreiber und der Festplatten-Firmware ist dies keine Garantie dafür, dass die Daten tatsächlich physisch auf die Festplatte geschrieben werden.

Gibt es eine .NET- oder Win32-Methode, die mir diese Garantie geben kann? Wenn also eine Nanosekunde nach der Rückkehr des Aufrufs dieser Methode ein Stromausfall auftritt, kann ich dann immer noch sicher sein, dass alles in Ordnung ist?

Answer 1

Stefan S. sagte:

Ich verstehe, dass die Flush-Methode von .NET FileStream nur den aktuellen Puffer auf die Festplatte schreibt

Nein, .NET FileStream's Flush schreibt nur die .NET-Puffer in den OS-Cache, es flusht den OS-Cache nicht auf die Festplatte. Leider steht das nicht in der MSDN-Dokumentation zu dieser Klasse. Für .NET < 4.0, müssen Sie Flush + Win32's FlushFilebuffers aufrufen:

using System.Runtime.InteropServices;
. . .

// start of class:
[DllImport("kernel32", SetLastError=true)]
private static extern bool FlushFileBuffers(IntPtr handle);
. . .

stream.Flush();     // Flush .NET buffers to OS file cache.
#pragma warning disable 618,612 // disable stream.Handle deprecation warning.
if (!FlushFileBuffers(stream.Handle))   // Flush OS file cache to disk.
#pragma warning restore 618,612
{
  Int32 err = Marshal.GetLastWin32Error();
  throw new Win32Exception(err, "Win32 FlushFileBuffers returned error for " + stream.Name);
}

Für .NET 4.0 können Sie stattdessen die neue Methode flush(true) verwenden. Update vom 11.09.2012: MS-Fehlerbericht aquí sagt, dass es kaputt ist, dann behoben, aber sagt nicht, in welcher Version oder welchem Service Pack es behoben wurde! Klingt, als ob der Fehler auftrat, wenn der interne .NET FileStream-Puffer leer ist und Flush(true) nichts bewirkt?

Answer 2

Unter Windows finden Sie unter FlushFileBuffers (Win32 API).

Answer 3

Nun, Sie könnten die Datei schließen... das würde wahrscheinlich genügen. In Wirklichkeit haben HAL-Abstraktion, Virtualisierung und Festplattenhardware heute mehr Verarbeitungsleistung und Cache-Speicher als Computer wie vor ein paar Jahren, müssen Sie sich damit abfinden, dass Sie hoffen, dass die Festplatte ihre Aufgabe erfüllt.

Das transaktionale Dateisystem hat sich nie wirklich durchgesetzt ;-p Natürlich könnten Sie vielleicht eine Datenbank als Backend verwenden und das Transaktionssystem dieser Datenbank nutzen?

Nebenbei bemerkt: nicht alle Streams garantieren auch die Flush() - zum Beispiel, GZipStream usw. behalten einen Arbeitspuffer mit unbestätigten Daten auch nach einem Flush - der einzige Weg, ihn zum Flush zu bringen alles soll Close() es.

Answer 4

Ich habe bemerkt, dass die .NET 4 #Flush(true) nicht tatsächlich auf die Festplatte schreiben. Wir hatten seltsame Probleme mit beschädigten Daten, und ich fand dies Fehlerbericht auf der MS-Website:

Auf der Registerkarte "Details" des Fehlerberichts können Sie ein Testprogramm ausführen, das das Problem aufzeigt;

1. Eine Reihe von Daten auf die Festplatte schreiben
2. fs.Flush(true) . Dies dauert keine Zeit (viel schneller als auf die Festplatte geschrieben werden kann).
3. Verwenden Sie die Win32-API FlushFileBuffers . Das dauert sehr lange.

Ich wechsle zum win32 FlushFileBuffers-Aufruf...

Answer 5

Die Dateidaten, die im Dateisystem-Cache gepuffert sind, werden auf die Festplatte geschrieben. Diese Daten werden normalerweise abhängig von der Position des Schreibkopfes auf der Festplatte geschrieben. Ein Gigabyte an zwischengespeicherten Daten ist technisch möglich und kann eine ganze Weile dauern. Wenn dies für Sie wichtig ist, sollten Sie die FileOptions.WriteThrough stattdessen die Option.