Wie schnell ist eine Datei wirklich sicher geschrieben (write‑cache und flush)?

1. Vorbereitung: Testgerät und Umgebung bereitstellen.
   Verwende ein verlässliches Testgerät. Nutze eine SD‑Karte oder einen USB‑Stick, den du verlieren darfst. Trenne nicht das Gerät, das du produktiv brauchst. Schließe das Medium an einen Linux‑Rechner an. Stelle sicher, dass du Root‑Zugriff für einige Prüfungen hast.
2. Geräte‑Status prüfen (Write‑Cache, Power‑Loss).
   Prüfe, ob das Laufwerk einen Schreibcache hat. Beispielbefehle: sudo hdparm -I /dev/sdX | grep -i cache und sudo sdparm --get=WCE /dev/sdX. Hinweis: Nicht alle Geräte unterstützen alle Tools. Achte auf Hinweise zu Power‑loss‑Protection in den Spezifikationen des Herstellers.
3. Einfacher Persistenz‑Test: Write + fsync + Reopen + Read.
   Schreibe eine Testdatei, rufe fsync auf, schließe die Datei, mounte das Medium neu und lies die Datei. Beispiel in Python:

   python3 - <<'PY'
   import os
   f=open('/mnt/test/testfile.bin','wb')
   f.write(b'X'*4096)
   f.flush()
   os.fsync(f.fileno())
   f.close()
   PY

   Danach sudo umount /mnt/test und wieder einhängen. Datei prüfen. Wenn Inhalt fehlt, war fsync nicht ausreichend oder Hardware hat Caching‑Probleme.

4. Mit strace verifizieren, dass fsync wirklich aufgerufen wird.
   Starte dein Schreibeprogramm unter strace und filtere fsync/fdatasync. Beispiel:

   strace -e trace=fsync,fdatasync -o /tmp/trace.log python3 write_program.py

   Kontrolliere die Logdatei. So siehst du, ob der Aufruf stattfand und ob er mit Erfolg endete.

5. Test mit O_SYNC oder O_DSYNC.
   Öffne die Datei synchron und schreibe. Beispiel in C oder bei Tools mit Flag. Das Verhalten ist langsamer. Es erzwingt persistente Writes pro Aufruf. Vergleiche Ergebnis mit dem fsync‑Test.
6. Blockdevice‑Flush testen (BLKFLSBUF / blockdev --flushbufs).
   Nutze als Root sudo blockdev --flushbufs /dev/sdX. Dieser Befehl fordert Kernel und Gerät auf, gepufferte Daten abzulegen. Verwende ihn vor dem Entfernen von Wechselmedien. Prüfe danach die Dateiintegrität wie oben.
7. Weitere Hardware‑Befehle prüfen (nvme flush, hdparm).
   Bei NVMe: sudo nvme flush /dev/nvme0n1. Bei SATA: sudo hdparm --flush /dev/sdX falls verfügbar. Diese Befehle nutzen Geräte‑spezifische Flush‑Semantik.
8. Aufbau für kontrollierte Power‑loss‑Tests.
   Verwende eine schaltbare Stromzufuhr, die du per Schalter oder Relais kurz unterbrechen kannst. Platziere das Medium an einem separaten USB‑Hub mit eigener Stromversorgung. Führe Schreibvorgänge aus und unterbreche die Stromzufuhr in definierten Zeitfenstern nach dem Schreiben. Nach Wiederherstellen der Versorgung überprüfe die Datei. Warnung: Das kann Geräte beschädigen. Nutze nur austauschbare Testmedien.
9. Testsequenz: verschiedene Zeitpunkte bei Stromunterbrechung.
   Starte mit diesen Zeitpunkten: unmittelbar nach write, direkt nach fsync, einige Sekunden nach fsync. Wiederhole jede Messung mehrfach. Notiere Erfolgsrate und Konsistenz. So erkennst du, ob Flush‑Befehle wirklich halten.
10. Ergebnisse auswerten und dokumentieren.
    Prüfe Prüfsummen oder Datei‑Inhalt. Nutze sha256sum für Vergleiche. Dokumentiere Anzahl erfolgreicher Wiederherstellungen pro Testfall. Ein Muster von Verlusten nach fsync deutet auf fehlerhafte Gerätfirmware oder auf nicht persistente Controller‑Caches hin.
11. Sicherheitsmaßnahmen und Tipps.
    Verwende für kritische Daten redundante Speicherung oder eine USV. Teste nicht auf Produktionsdaten. Wenn ein Gerät unsicher erscheint, deaktiviere Write‑Cache falls möglich mit hdparm -W 0 /dev/sdX. Beachte, dass manche Controller empfindlich auf solche Einstellungen reagieren.

Wichtige Warnhinweise