Glaub langsam, dass meine erste Platte einen Hau hat:
scan: scrub repaired 0 in 2h22m with 0 errors o
da die Fehler auf allen 3 Platten auftreten, ist es mit ziemlicher Sicherheit kein Plattenproblem. Ich vermute eher dass das RAW device mapping nicht nur nicht offiziell unterstützt wird, sondern eventuell auch problematisch ist.
ich habe da eh ein Verständnisproblem:
1. Die Platten werden vom Sata-Treiber von ESXi angesprochen
und als Raw-Disk durchgereicht. Jetzt wird es aber spannend:
Was trifft zu:
Die Platte wird von ESXi formatiert und komplett als eine Art Disk-Datastore
als komplette Platte zur Verfügung gestellt. Darauf legt Nexenta eine ZFS-Partition an.
oder:
ESXi rührt die Platte nicht an und reicht sie komplett durch.
Sie wird "nativ" als ZFS-Platte benutzt.
Im ersten Fall hat es nicht nur eine schlechte Performance sondern auch das
Problem, dass die Plattenkontrolle durch Nexenta sehr schlecht ist, ich denke
nur an den Aufwand, den Solaris beim syncronen Schreiben treibt.
Auch kann der Pool nicht einfach an einem anderen ZFS-Rechner importiert werden.
Im zweiten Fall hat es lediglich Performance-Abstriche wegen den zwei
Abstraktionsebenen (virtualisierter Nexenta SCSi-Treiber -> ESXI-Sata-Treiber -> Disk)
Hinzu können aber Timing-Probleme kommen. (Sind die Daten tatsächlich
auf der Platte, wenn ESXi dies bestätigt oder finden hier seitens ESXi
Performanceoptimierungen statt - mit der Folge, dass Nexenta Probleme bekommt.
Wie auch immer:
Ich denke nicht, dass RDM einen optimalen Weg darstellt, um ein StorageOS
zu virtualisieren.
Zum Testen würde es sich anbieten, Nexenta direkt (auf eine kleine Bootplatte oder USB)
zu installieren bzw. eine OpenIndiana Live-CD zu booten um dann zu sehen, ob es immer
noch Plattenprobleme gibt.
Gea