Server 2016 REFS, Storage Spaces

[Mr_Marple 15]

Hallo Forum!

 

 

Systeme: Virutelle VMS, Server 2012 R2 und Server 2016, jeweils 4 VHDs zu einem Pool zusammengefasst und als Mirror konfiguriert und mit REFS und aktiven Integrity Streams.

 

 

Es geht jetzt darum, dass bei 2016 anscheinend das Ereignisprotokoll nicht mehr wie bisher verwendet wird und auch, dass immer eine Warnung generiert wird.

Aber eines nach dem anderen.

 

 

Aufgabenplanung: Microsoft - Windows - DataIntegrityScan

Hier findet man den Task DataIntegrityScan, welcher das Volume auf Fehler prüft und die Integrity Streams auswertet und ggf. defekte Bits repariert.

 

 

Ereignisanzeige: Anwendungs- und Dienstprotokolle - Microsoft - Windows - DataIntegrityScan - Admin
Hier sind die entsprechenden Ereignisse drinnen.

 

 

Server 2012 R2:

Startet man den Task, werden keine Fehler protokolliert, sofern auch alles passt. Bild1

Wird nun die VHD mittels HEX Editor verändert, werden dann beim Task die defekten Blöcke mit den guten aus dem Mirror ersetzt und die Fehler protokolliert. Bild2

Folgende Einträge gibt es zu den Fehlern:

Protokollname: Microsoft-Windows-DataIntegrityScan/Admin
Quelle:        Microsoft-Windows-DataIntegrityScan
Datum:         31.10.2017 15:37:57
Ereignis-ID:   54
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      WIN-QEVPOGD900J
Beschreibung:
Eine Dateidateninkonsistenz wurde erkannt und erfolgreich repariert. Dateiname: E:\01010101.tst; Bereichsoffset: 0x35D50000; Bereichslänge (in Bytes): 0x4000: Reparierte Bytes: 0x4000; Status: STATUS_SUCCESS.





Protokollname: Microsoft-Windows-DataIntegrityScan/Admin
Quelle:        Microsoft-Windows-DataIntegrityScan
Datum:         31.10.2017 15:37:58
Ereignis-ID:   22
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      WIN-QEVPOGD900J
Beschreibung:
Die Volumeüberprüfung wurde abgeschlossen. Volumename: "E:\" (\??\Volume{97e5dc4b-61a7-4797-94c7-cb0df1937d6a}\); reparierte Bytes: 0x4000; nicht reparierte Bytes: 0x0; HResult: Der Vorgang wurde erfolgreich beendet..

Man sieht schön, welche Datei betroffen war, den Offset und die Länge des Defekts.

 

 

 

Bei Server 2016 gibt es nun den Unterschied, dass nichts mehr protokolliert wird.

Die Datei wird zwar brav repariert, aber ich sehe nichts davon im Ereignisprotokoll, dass ein Fehler aufgetreten ist.

 

Frage 1: Wie oder wo kann ich das nun auslesen?

 

 

Weiters gibt es bei 2016 einen Bug, der mich ziemlich bedenklich stimmt:

Oben habe ich zwar geschrieben, dass kein Fehler protokolliert wird, aber das stimmt nur bedingt.

Es wird beim Task immer ein Fehler protokolliert, egal ob eine defekte Datei vorhanden ist, das Volume frisch formatiert wurde oder die Integrity Streams gar nicht aktiv sind.

 

Das Protokoll sieht immer gleich aus, ob nun repariert wurde oder nicht. Bild3

Protokollname: Microsoft-Windows-DataIntegrityScan/Admin
Quelle:        Microsoft-Windows-DataIntegrityScan
Datum:         31.10.2017 15:34:54
Ereignis-ID:   56
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      WIN-874S4GJ1DUK
Beschreibung:
Eine Volumemetadaten-Inkonsistenz wurde erkannt und erfolgreich repariert.
Volumename: E:
Metadatenverweis: 0x204
Bereichsoffset: 0x0
Bereichslänge (in Bytes): 0x0
reparierte Bytes: 0x3000
Status: STATUS_SUCCESS.




Protokollname: Microsoft-Windows-DataIntegrityScan/Admin
Quelle:        Microsoft-Windows-DataIntegrityScan
Datum:         31.10.2017 15:35:03
Ereignis-ID:   22
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      WIN-874S4GJ1DUK
Beschreibung:
Die Volumeüberprüfung auf E:\ (\??\Volume{9e621f26-47d8-4dce-bd45-c255b2102d85}\) wurde abgeschlossen.
reparierte Bytes: 0x3000
nicht reparierte Bytes: 0x0
HResult: Der Vorgang wurde erfolgreich beendet.

Diesen Fehler habe ich mit einer VM und auch einer realen Maschine mit 4 HDs festgestellt. Somit glaube ich nicht, dass das nur Zufall ist.

 

 

Frage 2: Hat jemand eine Idee, was hier vor sich geht?

 

 

Das nicht protokolliert wird, wäre ja zu verkraften, aber dass auf einem frischen Volume ohne Daten immer Inkonsistenzen gefunden werden, macht mir Angst vor einem Umstieg!

Ist hier was verschlimmbessert worden?

 

LG & schönen Feiertag! :cool:

[Mr_Marple 15]

Hallo!

 

Hat schon jemand davon gehört?

Sollte ich das besser in einem MS Forum posten, da es sich ja offensichtlich nicht um eine lokale Anomalie, sondern um einen generellen Bug handelt?

[Doso 77]

Wir nutzen DPM 2016 mit Speicher mit ReFS (Modern Backup Storage). So. Viele. Bugs. 

 

Microsoft hat jetzt zwar immer mal wieder in Cumulative Updates irgendwas am ReFS Dateisystem rumgeschraubt, aber meist sind das dann Registry Parameter die man dann selber konfigurieren muss. Der DPM Server hat teilweise immer noch eine grottige Performance und die Ereignisanzeige ist voll von Fehlern und Warnungen die mit ReFS zusammen hängen. Immerhin stürzt der Server wegen Speichermangel nicht mehr ab...

 

Ich würde daher von Windows Server 2016 und ReFS aktuell noch die Finger lassen.

 

P.S: Das liegt defintiv an Windows Server 2016, bei Veeam gibt es die gleichen Probleme mit ReFS.

bearbeitet 5. Dezember 2017 von Doso