chkdsk Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist

[vmware-admin2016]

Hallo,

auf Grund manueller Backups sind Daten da.
OS 2012, trotzdem extrem ungünstig.

kann man so ein Verhalten erklären?
Könnte es sein, das Warnsignale vorher dagewesen sind?
Könnte es sein, das die HDD-Erweiterung anders hätte gemacht werden sollen?
(z.B. das neue Partition dranhängen immer 200% ungefährlicher ist?)

Situation: nach virtueller Festplattenerweiterung um einige hundert GBs im lfd. Betrieb von Laufwerk F:
ist eine 200GB Datenbankdatei weg.
Grund: chdsk startete automatisch bei windows-server-neustart
(diese Datei wurde nach der HDD Erweiterung neu erstellt auf F:)

Alle sonstigen "kleinen Logdateien" in dem selben Ordner sind unverändert da.
Der Raidmanager meldet keine defekte Festplatte, es ist esxi 6.
Große deutliche Anzeichen das Laufwerk F: vor-beschädigt sein könnte gab es m.W. nach nicht.

Code: Alles auswählen

Protokollname: Application
Quelle:        Microsoft-Windows-Wininit
Datum:         13.04.2023 11:47:06
Ereignis-ID:   1001
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      mailserver.contoso.local
Beschreibung:


Dateisystem auf F: wird überprüft.
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet Daten.


Einer der Datenträger muss auf Konsistenz überprüft werden.
Sie können die Datenträgerüberprüfung abbrechen, aber es
wird ausdrücklich empfohlen, den Vorgang fortzusetzen.
Die Datenträgerüberprüfung wird jetzt ausgeführt.                         

Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x41238c an für möglicherweise 0x4 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x942 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 2370 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x3a6467 an für möglicherweise 0x4 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x145f belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 5215 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0xa2ed6c an für möglicherweise 0x1 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x2922 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 10530 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x6e188e an für möglicherweise 0x10 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x298b belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 10635 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x3ad67f an für möglicherweise 0x10 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x356f belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 13679 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x125f824 an für möglicherweise 0x1 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x3688 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 13960 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x4cd2d79 an für möglicherweise 0x3 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x39b9 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 14777 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0xc77a64 an für möglicherweise 0x4 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x3dc0 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 15808 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x10ee22e an für möglicherweise 0x8 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x3e2a belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 15914 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0x46e527 an für möglicherweise 0x10 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x4196 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 16790 gelöscht.
Der Attributeintrag vom Typ 0x80 und mit der Instanzkennung 0x3 ist
von 0xfdd714 an für möglicherweise 0x10 Cluster quer verbunden.
Einige Cluster, die vom Attribut vom Typ 0x80 und der Instanzkennung 0x3
in der Datei 0x4610 belegt sind, werden bereits verwendet.
Beschädigter Attributeintrag (128, "") wird
vom Datensatzsegment 17936 gelöscht.
Beschädigter Eintrag in der Attributliste
mit Typcode 128 in Datei 18552 wurde gelöscht.

[~thc]

200 GB Datenbankdatei? "mailserver.contoso.local"?

Lass mich raten: Die Exchange-Datenbank?

Solange die virtuellen Festplatten "thick" sind, sollte das mit der online-Erweiterung immer funktionieren - bei mir bisher immer.
Auch für virtuelle Festplatten, auf denen eine Exchange-Datenbank liegt, gibt es nach meinem Wissen keine Einschränkungen.

Ob jetzt RAID-Controller oder ESXi einen Schluckauf hatten, können nur die ausführlichen Logs beider zeigen.

[vmware-admin2016]

ist denn Batterie des Cachemodule vom Raid Controller in diesem Zusammenhang wichtig?
ist denn das Raid Controller Cache Module in diesem Zusammenhang wichtig?

[~thc]

Das Cache-Modul und seine Batterie sind nur im Falle eines Stromausfalls gefragt.

Wenn der Controller das Volume im "Write Back" (mit Cache) Modus betreibt, muss natürlich der Cache fehlerfrei funktionieren.

[JustMe]

Aehm, das Windows IN der VM hat beim Neustart einen CHKDSK gestartet; also war das vorherige Herunterfahren VON WINDOWS unsauber. Dabei kann alles Moegliche mit der nicht sauber geschlossenen Datenbank passiert sein.

Alles in Allem sieht das dann doch eher nach einem Windows-Problem aus; der Zusammenhang zum Hypervisor wirkt hier eher konstruiert Das Vergroessern der Platte hat damit wohl kaum was zu tun. Es sei denn, Du haettest die VM just waehrend des Vergroesserungsvorgangs mutwillig abgewuergt, oder das Windows in der VM ist gerade bei diesem Vergroesserungsvorgang abgestuerzt.

Also mal Butter bei die Fische: Was fuer ein "Neustart" war das, und in welcher Situation?

Nichtsdestotrotz muss, wie ~thc anmerkte, ein WriteBack-Cache fehlerfrei funktionieren. Diese Aussage ziehe ich keinesfalls in Zweifel. Ich wuerde aber drauf tippen, dass ein solcher Cache-Fehler noch viel mehr Fehlersituationen verursachen wuerde (und mit dem Controller-Management-Tool [das dazu selbstverstaendlich mehr als ausgefallene Festplatten bemerken muesste] in den Logs auffindbar sein sollte).

[vmware-admin2016]

AFAIK:
Nein, der HDD Vergrößerungsvorgang war ohne besondere Vorkommnisse und über den vcenter Weg.
Die letzte ID:6008 im eventvwr ist ca. 30 Tage alt. (unerwartet heruntergefahren) bei diesem 2012er.
Ob das den ganzen Host betroffen hat weiß ich nicht.

Seitdem ca. 2-4 normale Neustarts gewesen und 2x merkwürdige extreme Langsamkeit morgens die nach Neustart weg war.
Keine dmp dateien im Minidump vorhanden (also kein BSOD)
Normale Neustarts vor 2-3 Tagen innerhalb von 10min fehlerfrei gewesen.
Eventvwr Quelle "Winit" = CHDSK hat nur genau einen Eintrag (vgl. hatte ich ja oben eingefügt)

Der unsägliche Neustart war in dieser Situation:
Postfachmigration von DB1 zu DB2 (beide auf gleicher partition) zu 80% fertig.
Postfach Migration kann man ja beenden, bzw. sozusagen pausieren beim EX 2013er, war vielleicht eine "offene prozedur", aber Status "beendet" war vor dem Neustart definitiv.

Serverneustart nicht ganz abwegig, weil die VSS Writer Status Orange hatten. (und logfiles dadurch nicht sauber bereinigt werden würden von Veeam B+R) und freier Speicherplatz knapp wurde.

Ja, Thick.

Vielleicht hätte der Informationsspeicher Dienst vor dem Neustarten beendet werden sollen. (wohl quatsch)