Datastore defekt nach Stromausfall

[kriegmi]

Hallo zusammen,

nach einem Neustart nach einem Stromausfall wird meine interne Festplatte SATA Samsung noch automatisch gemountet aber der Datastore wird ausgegraut dargestellt und er steht auf inaktiv nicht gemountet.

Wenn ich versuche den Datastore manuell zu mounten kommt folgende Fehlermeldung:

Code: Alles auswählen

Aufruf von "HostStorageSystem.MountVmfsVolume" für Objekt "storageSystem" auf ESXi "10.0.0.20" ist fehlgeschlagen.
Vorgang fehlgeschlagen, Diagnosebericht: Sysinfo error on operation returned status : Not supported. Please see the VMkernel log for detailed error information


im Kernel log unter /var/log/vmkernel.log steht:

Code: Alles auswählen

"2012-12-28T22:55:29.364Z cpu3:2672)<3>ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
2012-12-28T22:55:29.364Z cpu3:2672)<3>ata2.01: BMDMA stat 0x44
2012-12-28T22:55:29.364Z cpu3:2672)<3>ata2.01: cmd c8/00:08:88:ac:00/00:00:00:00:00/f0 tag 0 dma 4096 in
         res 51/40:07:89:ac:00/00:00:00:00:00/f0 Emask 0x9 (media error)
2012-12-28T22:55:29.364Z cpu3:2672)<3>ata2.01: status: { DRDY ERR }
2012-12-28T22:55:29.364Z cpu3:2672)<3>ata2.01: error: { UNC }
2012-12-28T22:55:29.606Z cpu3:2672)<6>ata2.01: configured for UDMA/133
2012-12-28T22:55:29.606Z cpu3:2672)<6>ata2: EH complete
2012-12-28T22:55:29.606Z cpu2:2050)NMP: nmp_ThrottleLogForDevice:2318: Cmd 0x28 (0x4124007c3d00, 2851) to dev "t10.ATA_____SAMSUNG_HD203WI_________________________S1UYJ1LZ110488______" on path "vmhba33:C0:T1:L0" Failed: H:0x0 D:0x2 P:0x0 Valid sense dat$
2012-12-28T22:55:29.606Z cpu2:2050)ScsiDeviceIO: 2322: Cmd(0x4124007c3d00) 0x28, CmdSN 0x17 from world 2851 to dev "t10.ATA_____SAMSUNG_HD203WI_________________________S1UYJ1LZ110488______" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x3 0x11 0x4.
2012-12-28T22:55:29.606Z cpu4:2851)FS3Misc: 1440: Long VMFS3 rsv time on 'data' (held for 1670 msecs). # R: 0, # W: 0 bytesXfer: 0 sectors
2012-12-28T22:55:29.606Z cpu4:2851)WARNING: HBX: 1889: Failed to initialize VMFS3 distributed locking on volume 4fe33828-b9bcaf9e-66ce-001b219f3df7: I/O error
2012-12-28T22:55:29.615Z cpu3:2851)FSS: 4333: No FS driver claimed device '4fe33826-c82ca0e8-4643-001b219f3df7': Not supported
2012-12-28T22:55:29.615Z cpu3:2851)LVM: 12007: Failed to mount 4fe33826-c82ca0e8-4643-001b219f3df7 (now umounting): Not supported


Es handelt sich um einen ESXI 5.0. Es gibt zwei Datastore´s. Der erste heist Datastore1 und liegt auf einer OCZ Vertex 3 256gb Festplatte. IN diesem Datastore befinden sich die server. Der 2 Datastore heist Data dieser ist momentan defekt iund liegt auf einer 2 TB Samsung Festplatte in ihm befinden sich zusätzliche Virtuelle Festplatten die den Servern zugeordnet sind. Beide Datastore sind vom TYP VMFS-5.

Hat irgend jemand eine Idee wie ich den Datastore retten kann?

Vielen dank im voraus.

Grüße
Michael

[kriegmi]

Hallo zusammen,

hat keiner eine idee?


grüße Michael

[continuum]

Hi Michael

No FS driver claimed device '4fe33826-c82ca0e8-4643-001b219f3df7': Not supported

Das gefaellt mir ganz und gar nicht.
Lad dir mal
http://sanbarrow.com/mcs-esxi5-recovery-X-001.iso
runter und schick mir ne PM mit Telefonnummer - dann melde ich mich nach Mittag mal bei dir

[~thc]

H:0x0 D:0x2 P:0x0 Valid sense data: 0x3 0x11 0x4

ESX:
SG_ERR_DID_OK (0x0)
CHECK CONDITION (0x2)
NO ERROR (0x0)

Sense data:
MEDIUM ERROR (0x3)
UNRECOVERED READ ERROR (0x11)
AUTO REALLOCATE FAILED (0x4)

Die Platte ist höchstwahrscheinlich im Eimer - sie mochte deinen Stromausfall wohl gar nicht. Du kannst sie ja mal in einem anderen PC/System analysieren - aber mach dir keine großen Hoffnungen.

[Dayworker]

Es hat halt schon seinen Grund, weshalb VMware keine einfachen HDDs als Datastore supportet.
Mit etwas Glück kämpfte deine Platte aber auch nur mit einer Aufladung aufgrund eines Blitzeinschlags in der näheren Umgebung. Inzwischen sollte diese jedoch abgebaut und der Zugriff wieder möglich sein.

[continuum]

Auf der Platte ist immer noch VMFS drauf - allerdings sind die files die beim Stromausfall offen waren zumindest teilweise hin.

[Dayworker]

Code: Alles auswählen

2012-12-28T22:55:29.606Z cpu4:2851)FS3Misc: 1440: Long [b]VMFS3[/b] rsv time on 'data' (held for 1670 msecs). # R: 0, # W: 0 bytesXfer: 0 sectors

...
Beide Datastore sind vom TYP VMFS-5.

Stimmt deswegen der VMFS-Typ nicht überein oder bleibt die VMFS-Typerkennung erhalten, wenn man den DS nur von VMFS3 unter Beibehaltung der bisherigen Blockgrösse updatet?

Auf der Platte ist immer noch VMFS drauf - allerdings sind die files die beim Stromausfall offen waren zumindest teilweise hin.

Ein Datenverlust beim Plattenzugriff und Stromausfall ist absolut nichts ungewöhnliches und kann mit der gleichen Konsequenz genauso auch unter Linux und Windows auftreten. Im Normalfall würde man jetzt sein aktuellstes Backup oder je nach persönlicher Aufwandsbereitschaft nur einzelne Dateien daraus einspielen.

[UrsDerBär]

@kriegmi/Continuum: Kannst du etwas zum Festplattenschreibcache sagen? Aktiviert oder deaktiviet?

Sprich: Wenn man via einem HBA/RAID-Controller geht welcher den Schreibcache der Platten deaktiviert, passiert das auch oder eher nicht?

[continuum]

Ich wuerde die Chance fuer einen Datenverlust nach Stromausfall bei VMFS deutlich hoeher einschaetzen als bei Linux-dateisystemen wie zB. ext3.

Wenn man beim ESXi zwischen VMFS, ext3 oder NTFS waehlen koennte - wuerde ich ohne Zweifel NTFS nehmen.

[Dayworker]

Wenn man beim ESXi zwischen VMFS, ext3 oder NTFS waehlen koennte - wuerde ich ohne Zweifel NTFS nehmen.

Klare Worte, ich hätte sie nur nicht in dieser Deutlichkeit erwartet.
Gibts dafür eigentlich bestimmte Gründe?

@kriegmi/Continuum: Kannst du etwas zum Festplattenschreibcache sagen? Aktiviert oder deaktiviet?

Sprich: Wenn man via einem HBA/RAID-Controller geht welcher den Schreibcache der Platten deaktiviert, passiert das auch oder eher nicht?

Ausgehend von seinen Angaben würde ich sagen, daß zum einen der HBA den Plattencache nicht deaktiviert hat und das zum anderen aufgrund meiner Erfahrungen auch ein deaktivierter Plattencache bei geöffneten Dateien an dem Verlust nichts geändert hätte. Selbst ein Raid1 würde sich zumindest über ein nicht sauber heruntergefahrenes Volume beschweren und da inzwischen jedes OS auch irgendwo Performancedaten wegschreibt, kann jeder Stromausfall ohne BBU oder zumindest USV (am besten wäre natürlich beides) zu einem mehr oder minder schweren Datenverlust führen.

[UrsDerBär]

Bei NTFS braucht es erfahrungsgemäss ziemlich viel bis nichts mehr geht. So Horrorszenarien wie hier öfter mal mit VMFS zur Sprache kommen habe ich noch nicht erlebt.

Ist halt schwierig was man in Miniumgebungen unter VmWare als Storage nimmt. Günstige iSCSI-Lösung wie Qnap's bzw. Datastores da drauf finden Stromunterbruch bestimmt auch nicht toll. Auch die Stores auf den richtigen Teile dürften trotz Cache kaum erfreut sein.

@Dayworker: USV ist ja eigentlich eh Pflicht. RAID-Controller mit Cache: Hmm gut, vielleicht bringts noch etwas mehr als nur Festplatten-Cache deaktivieren. Zumindest wenn das OS dadurch vielleicht Daten noch in den Cache gebracht hat. Mitten in Speichervorgängen dürfte das Hans was Heiri sein oder sehe ich das falsch?

[continuum]

Wenn man beim ESXi zwischen VMFS, ext3 oder NTFS waehlen koennte - wuerde ich ohne Zweifel NTFS nehmen.

Klare Worte, ich hätte sie nur nicht in dieser Deutlichkeit erwartet.
Gibts dafür eigentlich bestimmte Gründe?

Ja - zum einen gibt es bei VMFS selbst in Version 5.1 immer noch kein checkdisk-tool das reparieren kann. Man kann schon froh sein dass es mittlerweile mit VOMA ein Tool gibt , das Fehler feststellen kann - aber um das laufen zu lassen muss man das Datastore still-legen !
Dann ist VMFS nicht ansatzweise dokumentiert - das heisst kein Thirdparty-hersteller kann Recoverytools oder checkdsisk-tools anbieten.

Ontrack koennte das - die behalten ihr spezial Knowhow aber fuer sich.

Dann guck dir mal an wie oft man nach einem Stromausfall die Partitionstabelle neu schreiben muss. Das ist ein Witz - es gibt keinen guten Grund warum ein System ueberhaupt die Partitionstabelle offen im RAM liegen haben muss. Readonly sollte voellig reichen

AFAIK gibt es bei VMFS nur eine Version des Journals fuer Schreibaktionen - selbst bei FAT32 gab es - wenn ich mich nicht irre schon 2 FATs (file allocation table).
Bei NTFS gibt es 2 mal den MFT - aus gutem Grund.

[Martin]

NTFS ist aber auch nicht komplett offen dokumentiert

[continuum]

Klar - der Vergleich hinkt - allein schon weil NTFS auf Milliarden Computern laeuft und daher das Interesse von thirdparty Anbietern viel hoeher ist.

Aber bei MS findet man zB Anleitungen zum Beheben von Problemen wie defekte Partitions-boot-sektoren oder defektem MFT.

Bei VMFS weiss man noch nicht einmal welche .sf Datei wofuer gut ist