Ich möchte an dieser Stelle alle warnen, die daran denken, einen (onboard) Silicon Image 3114 (oder 3112) Controller unter Solaris 10 zu nutzen. Wir haben vorletzten Samstag, den 24.02.2007, auf einem solchen mit dem Solaris 10 Software RAID einen Webserver aufgesetzt, der massig Zugriffe ertragen muss. Bei der Installation lief alles problemlos, außer der Tatsache, dass die S-ATA Platten extrem langsam waren (25MB/s beim Schreiben, 50MB/s beim Lesen - bei nagelneuen 250GB 7.200rpm S-ATA Platten die normalerweise einzeln ca. 60MB/s schreiben und lesen). Aber da auf den S-ATAs lediglich das System sowie ein kleiner Datenspeicher geplant waren, war uns das relativ egal. Die wichtigen Daten liegen ohnehin auf zwei separaten SCSI ZFS Mirrors, einmal für Apache/TMP/Logs/Swap (zwei 140GB 10.000rpm SCSI) und einmal exklusiv für MySQL (zwei 36GB 15.000rpm SCSI).
Wie dem auch sei – Donnerstag gegen 13:15 Uhr ist unser Solaris eingefroren und hat nur noch im Single User Mode gebootet. Im RZ selber mussten wir dann feststellen, dass auf beiden RAID1 S-ATA Platten nur noch Datenmüll vorzufinden war. Vereinzelt auch noch korrekte Dateien aber größtenteils unbrauchbar und zerstört. Wir wissen nicht genau woran es lag, aber definitiv nicht an den S-ATA Platten selber – haben wir mittlerweile getestet und sind einwandfrei. Die beiden SCSI-RAIDs waren davon nicht betroffen, die sind in Ordnung und nicht kompromittiert – es waren wirklich ausschließlich die beiden S-ATA am SIL3114 von dem Problem betroffen. Jetzt gibt es theoretisch nur drei Möglichkeiten:
#1: Der Treiber. Der SIL3114 ist unter Solaris lediglich „known to work“ und nicht offiziell unterstützt. Er ließ sich jedoch problemlos einbinden und betreiben, bis auf die miserable Performance eben. Und am Development Server läuft bis heute ein Solaris 10 im Software RAID an einem SIL3114 installiert völlig fehlerfrei. Allerdings muss der Development Server natürlich auch nicht die Last des Produktiv-Servers ertragen.
#2: Der Controller selber hat einen an der Patsche und Müll geschrieben. Recht unwahrscheinlich, da er bereits ein Jahr lang davor im Einsatz war unter Debian Linux, zwar nur mit einer einzelnen Backup-Platte aber dennoch im Einsatz, und das völlig fehlerfrei und problemlos
#3: Wir sind dem AMD-Chipsatz PCI-Bug aufgesessen, der bei aktiviertem Delayed Transaction bei drei PCI Busmastern aufgrund eines Pufferüberlaufs anfängt Müll zu produzieren (sehr ähnlich dem VIA 686B Southbridge Bug). Auch sehr unwahrscheinlich, es waren zwar drei Busmaster aktiv (an diesem PCI-Bus hängen Grafikchip (ATI Rage XL), 100 MBit Ethernet (deaktiviert), IDE-BUS (DVD-ROM) sowie eben der SIL3114), und Delayed Transaction lässt sich bei diesem Board nicht deaktivieren (Tyan 2882D-GNR3 mit zwei Opteron 290 CPUs), aber zuvor hingen unter Linux sogar vier Geräte an diesem Bus (das RZ hat erst im letzten Jahr die Switches von 100 Mbit auf 1 Gbit umgestellt, daher jetzt der Umstieg auf Gigabit Ethernet (angebunden am zweiten 100 MHz PCI-X Bus) und der Verzicht auf die 100Mbit Ethernet Schnittstelle) und es gab keinerlei Probleme oder gar entfernte Anzeichen dafür.
#4: Timing-Problem bei SMP-Maschinen und SoftRAIDs. Wäre evtl. auch eine Möglichkeit, da zuvor unter Linux ein ICP Vortex Hardware-RAID Controller zum Einsatz kam, der aber wegen miserabler Performance (50MB/s schreibend an zwei 10.000rpm SCSI-Platten, einzeln rund 72MB/s) rausfliegen musste. Allerdings hätte es dann auch auf den SCSI-Platte Probleme geben müssen und die beiden SCSI-RAIDs sind einwandfrei in Ordnung. Also auch eher unwahrscheinlich.
Der am wahrscheinlichsten Verantwortliche für diesen Ausfall ist also, meiner Meinung nach, der Treiber für den SIL3114 Controller oder aber der Controller selber. Hat jemand Erfahrungen mit dem SIL3114 und kann etwas dazu beitragen?
Thema: ACHTUNG! SIL3114 hat Software RAID zerschossen (Gelesen 6437 mal)