SMR Disk und Stromausfall

[zt478]

Nachdem ich die letzten Tage mit schwebenden Sektoren beschäftigt war, gab es heute die nächste Katastrophe: während des Kopieren einer 50 GB Datei von einer SMR Disk auf eine andere SMR Disk fiel der Strom aus!
Auf der Quell Disk könnten auch noch ein paar Sektoren noch nicht geschrieben worden sein, denn chkdsk hat in den kurz vorher gelöschten Dateien Inkonsistenzen gefunden. Auf der Ziel Disk hat chkdsk nichts gefunden.

Die spannende Frage ist ob auf Grund der SMR Eigenschaften nicht nur die zuletzt geschriebene Datei unvollständig ist, sondern ob auch andere Dateien geshreddert oder geshingeld sind. In den Smart Meldungen der beiden Platten sind keine Fehler zu sehen. Hat jemand hier Erfahrungen zur Sicherheit von SMR Platten?

 

[Inzersdorfer]

Das sollte eigentlich nicht vorkommen, neue Daten werden ja in den On-Disk-Cache geschrieben, bzw. wenn der bei Dateien gößer als dieser Cache vollläuft direkt, langsam, auf das Userland (der Bereich der den Usern zugänglich ist). Nur wenn der Dateitransfer inkomplett war, etwa durch den erwähnten Stromausfall, würden die Daten verworfen. Das sollte sich aber nicht auf das Quelllaufwerk auswirken, auch andere vorher auf das Ziellaufwerk überspielte vollständige Dateien sollten erhalten sein.

Deine Beschreibung ist nicht exakt: einerseits "während des Kopieren", anderseits: "chkdsk hat in den kurz vorher gelöschten Dateien Inkonsistenzen gefunden"?

 

[zt478]

Wenn beim Schreiben großer Daten der Cache des Ziellaufwerk voll läuft und direkt geschrieben wird, müssen ja alle Daten in der Zone gelesen und neu geschrieben werden. Welche Dateien davon betroffen sind, lässt sich nicht beantworten. Die Frage ist ob dabei Daten verloren gehen können, wenn der Stromausfall mitten im Datei kopieren passiert.

Ich hatte irgendwann kurz vor dem Stromausfall ein paar Daten auf der Quelle gelöscht. Beim Chkdsk kamen dann Korrekturmeldungen zu den Dateien im Papierkorb, ob ich den Papierkorb schon geleert hatte, kann ich nicht sagen.

Auszug aus dem Eventlog chkdsk für die Quelle:
Phase 2: Die Dateinamenverknüpfung wird untersucht...
12 Analysedatensätze verarbeitet. Es wurde eine unnötige Verknüpfung ($FILE_NAME: "$R4JHSUL.ffs_db") in Index "$I30" von Verzeichnis "\$RECYCLE.BIN\S-1-5-21-2734707977-3600209164-1931413314-1001 <0x1,0x77b>" gefunden.
...online repariert.
Es wurde eine unnötige Verknüpfung ($FILE_NAME: "$R67XHKH.ffs_db") in Index "$I30" von Verzeichnis "\$RECYCLE.BIN\S-1-5-21-2734707977-3600209164-1931413314-1001 <0x1,0x77b>" gefunden.
...online repariert.
Es wurde eine unnötige Verknüpfung ($FILE_NAME: "$REGASFI.ffs_db") in Index "$I30" von Verzeichnis "\$RECYCLE.BIN\S-1-5-21-2734707977-3600209164-1931413314-1001 <0x1,0x77b>" gefunden.
...online repariert.
Es wurde eine unnötige Verknüpfung ($FILE_NAME: "$RI1JQDH.ffs_db") in Index "$I30" von Verzeichnis "\$RECYCLE.BIN\S-1-5-21-2734707977-3600209164-1931413314-1001 <0x1,0x77b>" gefunden.
...online repariert.
6220 Indexeinträge verarbeitet. Indexüberprüfung beendet.
Phasendauer (Indexüberprüfung): 655.24 Millisekunden.

Phasendauer (Wiederverbindung für verwaisten Datensatz): 3.36 Millisekunden.

Phasendauer (Wiederherstellung für verwaiste Datensatz): 1.35 Millisekunden.
12 Analysedatensätze verarbeitet. Phasendauer (Überprüfung von Analysepunkts und Objekt-ID): 8.51 Millisekunden.

Phase 3: Sicherheitsbeschreibungen werden untersucht...
Überprüfung der Sicherheitsbeschreibungen beendet.
Phasendauer (Überprüfung für Sicherheits-Deskriptor): 10.44 Millisekunden.
422 Datendateien verarbeitet. Phasendauer (Datenattributüberprüfung): 0.49 Millisekunden.
Es wurden Probleme erkannt, die alle online behoben wurden.
Es sind keine weiteren Aktionen erforderlich.

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...

Phase 2: Die Dateinamenverknüpfung wird untersucht...
Der Indexeintrag $R4JHSUL.ffs_db von Index $I30 in der Datei 0x77b verweist auf die nicht verwendete Datei 0x13b6.
Indexeintrag $R4JHSUL.ffs_db in Index $I30 der Datei 77B wird gelöscht.
Der Indexeintrag $R67XHKH.ffs_db von Index $I30 in der Datei 0x77b verweist auf die nicht verwendete Datei 0x13be.
Indexeintrag $R67XHKH.ffs_db in Index $I30 der Datei 77B wird gelöscht.
Die Dateireferenz 0x10000000001275 von Indexeintrag $REGASFI.ffs_db von Index $I30 mit dem
übergeordneten Element 0x77b ist nicht die gleiche wie 0x12000000001275.
Indexeintrag $REGASFI.ffs_db in Index $I30 der Datei 77B wird gelöscht.
Der Indexeintrag $RI1JQDH.ffs_db von Index $I30 in der Datei 0x77b verweist auf die nicht verwendete Datei 0x130f.
Indexeintrag $RI1JQDH.ffs_db in Index $I30 der Datei 77B wird gelöscht.

 

[Inzersdorfer]

Wenn bei einem Stromausfall kopierte Dateien nur in Teilen geschrieben wurden, werden sie hier anschließend als ungültig verworfen, verloren gehen sollten in so einem Fall Daten nicht, sie sind ja auf dem Quelllaufwerk noch vorhanden, werden Daten vollständig auf die SMR gecacht sollte auch bei einem Stromausfall kein Datenverlust entstehen da IMHO der Cache erst nach Anlegen der endgültigen Speicherbereiche gelöscht wird.

 

[zt478]

Sieht so aus als ob nichts passiert ist. Ich habe bereits einiges auf den beiden Platten binär verglichen und noch keine Fehler festgestellt. Normalerweise nutze ich keine "Schummel" Platten, aber hier war der Preis und der geringe Leistungsverbrauch entscheidend. Wenn die Daten erst mal drauf sind, ändert sich so gut wie nichts mehr daran und es wird nur noch gelesen. In den Rechner selber kommt mir sowas nicht.

 

[gea]

Man muss unterscheiden.

Neuere MSR haben einen "Mediacache". Das ist quasi ein CMR Bereich auf der Festplatte. Was da gespeichert ist, bleibt bei Stromausfall erhalten.

Daneben gibt es einen Ramcache. Dessen Inhalt geht verloren genau wir bei CMR Platten.