Haben 2 verschiedene SYnology-Storages im Einsatz, eine RS814RP und eine DS2413+.
In der RS814RP laufen die Platten ohne Probleme, in der DS2413+ gehen die kaputt, allerdings erst nach Monaten.
Die Kompatibilitätslisten weisen das (mittlerweile?) auch aus.
Interessanterweise steht die ST3000VX000 bei keiner Storage in der Liste, die mehr als 8 Einschübe hat und auch bei keinem Expansionmodul, das mehr als 5 Einschübe hat.
Sowohl die ST4000VX000, als auch die ST3000VX002 stehen aber drin.
Im Datenblatt der Surveilance Serie 35 (
http://www.seagate.com/www-content/...gb/docs/surveillance-hdd-ds1679-10-1406gb.pdf) ist als Unterschied angegeben, daß die ST3000VX000 nur bis zu 6 Bays unterstützt, die ST4000VX000 und die ST3000VX002 jedoch bis zu 16. Der Hintergrund dafür sind m.E. Unterschiede in der RV-Sensorik, die hochfrequente Vibrationen erkennt und deren Ausgleich damit ermöglicht.
Bei der DS2413+ war das Verhalten so, daß die Smart-Fehler hochgezählt haben und dann irgendwann Platten ausgefallen sind. Das war interessanterweise spezifisch bei verschiedenen - und immer denselben! - Einschüben. Besonders bemerkenswert ist, daß die Platten immer zeitgleich ausfielen, oft während des Rebuilds. Wenn das erfolgte, dann hat die DS2413 einen Kernelfehler ins Log geschrieben und die Block-Level-LUN offline genommen. Versuchte Neustarts führten dazu, daß SSH und die Management-Schnittstelle abgeschaltet wurden, die Storage jedoch nicht neu startete - mußte ausgeschaltet werden. Dieses Verhalten tritt immernoch auf - Aktuelles DSM 5.1.
Dadurch, daß mehr Festplatten mehr Schwingungen erzeugen und das mehr Fehler erzeugt, die dann während des Rebuilds zu Problemen führen (Laufwerke gehen offline, Storage zeigt an, es sei alles in Ordnung, es werde lediglich eine Paritätsprüfung im Hintergrund durchgeführt, die aber bei einer bestimmten Prozentzahl stehenbleibt), tritt die paradoxe Situation auf, daß die Storage, nachdem die Hotspare-Platten und die Paritätsplatten entfernt wurden, wieder solange lief, daß die Daten herunterkopiert werden konnten - was zunächst zu der Schlußfolgerung verleitete, daß ein Fehler in der Linux-Raid-Implementierung vorliegen würde (der liegt tatsächlich vor, aber nur dahingehend, daß beim Rebuild ein Deadlock auftritt, wenn IO-Fehler auftreten und der Rebuild NICHT abgebrochen wird, sondern sich festhängt) oder im DSM (auch da liegt tatsächlich der Fehler vor, daß die in der GUI angezeigten Informationen nicht mit denen übereingestimmt haben, die mdadm zurückgeliefert hat - welche Platten aus dem Sync sind, sieht man z.B. garnicht).
Als Vergleich haben wir auch eine QNAP Storage (TS-EC879U-RP), die listet die ST3000VX000 als kompatibel auf (ebenso, wie die 8-bay Synology-Modelle), die höheren Storages bis 16 Bays aber auch - lediglich das 24bay-Modell nicht. Die ST3000VX002 wird allerdings nicht mit aufgeführt. Daß bei QNAP die Laufwerke als kompatibel eingestuft werden, bei Synology jedoch nicht (und das auch nicht sind bei mehr als 8 bays) hängt möglicherweise mit einer anders konstruierten Aufhängung zusammen.
Als Fazit: Bei mehr als 4 Platten immer schauen, welche Einschränkungen der Plattenhersteller macht; auch innerhalb einer Baureihe gibt es da mitunter deutliche Unterschiede. In den Kompatibilitätslisten der Storages findet sich das dann auch wieder.
