DSM 6.x und darunter DSM 6.2.1-23824 Update 1

[MucMario]

kurzes Zwischenupdate:

- Seagate tauscht nur gegen gleiches Modell (Standardprozedur), das ist zwar "löblich" aber hilft nicht bei der Ursachenbehebung
- Firmware für die beiden 10TB ist SC60 und der aktuelle Stand (es gibt also kein Update derzeit)
- der Fehler wird von Seagate als "unbekannt" tituliert & Synology hüllt sich leider immer noch in Schweigen

Kurzum: Ich werde jetzt eine Rückgabe beim Händler versuchen; der hat aber schon angedeutet, daß er die Platten nicht "als defekt" ansieht, denn es tritt ja bisher nur bei Synology auf... Situation ist also denkbar super: Ein Kunde, drei Firmen, die die Verantwortung munter hin und her schieben.

 

[pamper]

...wobei ich die Händlerposition noch verstehen kann. Löblich von Synology ist ja, daß sie um einen möglichen Schaden von uns Benutzern abzuwenden, den Cache vorsorglich deaktiviert haben. Nicht nachvollziehbar ist aber, daß da dann wohl (?) kein Informationsfluß über den Fehler von Synology an Seagate erfolgte?! Die kooperieren doch? Siehe auch das "tolle Ironwolf-Health" - ach ich vergaß, dass zeigt ja gar nicht solche Kleinigkeiten im Synology-NAS Test an.

 

[MucMario]

Update:

Synology sagt, daß offenbar die Modelle ST10000NE0004, ST10000VN0004 , ST12000VN0007, ST14000VN0008 betroffen sind. Bestätigen kann ich nur die erste, da ich genau die einsetze.

Seagate kann mit dem Problem nichts anfangen ("unbekannt"); Kommunikation untereinander nicht bekannt bzw. nicht (für mich) zur Verfügung gestellt.

Händler verweigert Rücknahme, da er ja nicht garantiert hätte, daß die NAS(!)-Platten im Synology-NAS laufen...

Mal schauen, wie lange meine Geduld noch anhält, es ist echt zum Mäusemelken, diese Servicewüste.

 

[pamper]

Danke für das Update! Da kann man nur hoffen, daß das Problem mehr Leuten bewusst wird/auffällt und publik wird. Dann steigt vielleicht so der Druck auf Seagate (Synology?), daß Thema anzugehen.

 

[cane11]

Danke dass hier einige hier an einer Problemlösung arbeiten. Ich für meinen Teil habe das DSM 6.2.1-23824 Update 1 bis jetzt ausgelassen, da alles bei meiner DS218+ läuft wie gewünscht.
Mal sehen was ihr erreichen könnt

 

[3615]

@MucMario
Danke, dass du bei Seagate+Synology nachgefragt hast. Ich bin mit mehreren 10TB IronWolfs in der selben Situation.
Weder Händler noch Seagate sind die richtigen Ansprechspartner sondern Synology. Sie haben die Cache Funktion in der neusten DSM Version still und heimlich deaktiviert ohne es mit Anwendern zu kommunizieren.
Anhand des Festplattenverhaltens habe das Gefühl, dass die Cache Deaktivierung schon mit der Einführung der Hauptversion und nicht seit dem U1 stattgefunden hat.
Die ganze Geschichte mit der grossen Kooperation zwischen Seagate und Synology scheint leider eine reine Marketing Story zu sein.

 

[Archi_74]

Nachdem Synology meine 3 Tickets zu dem Problem inzwischen versanden lassen hat, habe ich noch einmal nachdrücklich um Aufklärung gebeten.
Mit den bisherigen Rückantworten in meinen Tickets möchte ich mich nicht zufrieden geben.

Es kann doch nicht angehen, dass nach außen hin eine tolle Zusammenarbeit zwischen Synology und Seagate suggeriert wird und Synology die Ironwolf Reihe für die besten HDDs für ihre Produkte hält, gleichzeitig aber den Schreibcache aus Kompatibilitätsgründen abschaltet. Mit keiner Silbe wird eine Aussicht auf Ursachenforschung bzw. eine Behebung des Problems gestellt.
Ich sitze ich hier auf fast 2 Dutzend 10 TB Ironwolfs die in ihrer Leistung beschnitten sind. Dafür sind über 6.000,- € einfach zu viel Geld!

 

[MucMario]

ja, ich könnte mich der überlegung anschliessen, dass das ein reines synology thema sein könnte.

bei der "nachrichtenlage" jedoch ist jegliche diagnose unmöglich - ich kann nur empfehlen, weiterhin druck zu machen.

ist vielleicht auch mal einen heise-artikel wert, vllt kann man die informieren (ich hab's schon gemacht). könnte mir vorstellen, dass davon einige "gewichtige" profi-anwender betroffen sind.

...und (un)auffällig: in der HCL findet sich immer noch kein hinweis auf das problem, das ist ein witz.

p.s. zum glück habe ich nur zwei von den dingern im/n betrieb; wenn mir die geduld reisst, dann werde ich nochmal 800 ausgeben (aka zum fenster hinauswerfen) und wd kaufen (diesmal mit dem auf der rechnung verbrieften hinweis der 100% kompatibilität, man lernt ja dazu).

 

[himitsu]

Es kann doch nicht angehen, dass nach außen hin eine tolle Zusammenarbeit zwischen Synology und Seagate suggeriert wird und Synology die Ironwolf Reihe für die besten HDDs für ihre Produkte hält, gleichzeitig aber den Schreibcache aus Kompatibilitätsgründen abschaltet.

Die arbeiten doch zusammen?
Bei Problemen sorgt einer der Beiden schnell für eine Lösung. (hier eben durch Abschalten des problembehafteten Bauteils)

Und durch einen SSD-Cache lässt sich das Problem der Problembehandlung dann ebenfalls eliminieren.

[ironie aus]

 

[felge88]

Empfehlungen für eine gute leise Festplatte für den DS718+ ?

 

[synfor]

Das ist der falsche Thread. Außerdem, warum bleibst du damit nicht in deinem bereits bestehenden Thread?

 

[MucMario]

salut zusammen

mir reicht es dann jetzt, sorry, aber ich habe gestern beschlossen, das thema zu beenden:

- seagate schreibt wieder "austauschen" (gg gleiches modell, also leider nicht hilfreich)
- synology schreibt "wir sagen nix, aber der cache geht NUR bei diesem modell nicht" (was nicht stimmt, denn auch andere modelle sind betroffen, ahnungslosigkeit)
- händler schreibt "bitte einschicken, dann gucken wir mal, was wir machen" (da kann ich ohne zensurfilter garnix schreiben, die platten sind ja gerade 3 monate alt...)

fazit für mich: "alte" platten fliegen raus, neue sind bereits in der post. damit endet mein ausflug in die seagate welt, auch wenn nur "ein fall", subjektiv usw. habe ich die nase voll, auch wenn das problem vllt ursächlich noch woanders zu verorten ist.

hätte mich auch von synology trennen können, aber der switch ist noch zu teuer (vulgo: aufwändig). werde aber in zukunft beachten: keine monokultur mehr - gibt ja wettbewerb.

 

[pamper]

Moin,
verständlich Dein Vorgehen! Ich selbst habe beschlossen aktuell noch durchzuhalten bzw. möchte ich meinen, noch offenen Call bei Synology auch fertig abwarten. Spiele natürlich auch mit dem Gedanken, zu anderen HDDs (WD) zu wechseln und mein Seagate-Experiment auch zu beenden - auch wenn dieses eine Mal keine (richtig) defekte Seagate-Platte dran Schuld hat...

 

[Puppetmaster]

Schade, dass der User @seagate_surfer hier nicht mal einen Ton dazu sagt, immerhin liest er ja zumindest noch sporadisch hier im Forum mit.
Seine Aussagen kämen dann auch direkt vom Hersteller, wären somit auch belastbar, insbesondere was die sog. Zusammenarbeit von Seagate und Synology betrifft.

 

[peterhoffmann]

Schade, dass der User @seagate_surfer hier nicht mal einen Ton dazu sagt, immerhin liest er ja zumindest noch sporadisch hier im Forum mit.

Vielleicht hat er es einfach nur bisher übersehen.
Ich habe ihm mal eine PN geschickt und einen Link zum Thread reingepackt.

 

[Archi_74]

Habe nun auf mein wiederholtes Ticket eine für mich eindeutige Antwort vom Support erhalten. So wie es aussieht ist das Problem
mit dem Schreibcache der Ironwolfs für Synology erledigt und abgehakt.

Zitat:

"Hallo,

der write cache wurde deaktiviert da es ansonsten in einzelnen Fällen zu timeouts und in der Folge zu einem fehlerhaften RAID (crash) kommen kann.

Nach erweiterten Tests von uns als auch von Seagate selbst gibt es hier keine Performance-Einbußen, da dieser Festplattentyp eine höhere Geschwindigkeit in der Verarbeitung erreicht, als das Modell DS1618+ über die interne Hardware bereitstellen kann. Es entsteht daher in dieser Kombination keinerlei Nachteil bei deaktiviertem write cache; bzw Sie würden keinerlei Geschwindigkeitsvorteil haben wenn das write cache aktiviert wäre."

Für mich ein absolutes NoGo und ich habe gerade eine ziemlich dicke Krawatte am Hals!!! Dieses Vorgehen wird dem Endkunden bisher nicht kommuniziert. Man kauft also
nach Empfehlung seitens Synology IronWolf und heraus kommt eine Syno mit beschnittener Hardware.

Meiner Überlegung nach dient doch gerade der Cache der HDDs um Schreibzugriffe mit entgegen den Lesezugriffen zu koordinieren und zwischenzupuffern.
Korrigiert mich wenn ich falsch liege, aber bei augeschaltetem Cache arbeiten die HDDs stur die Daten ab. Egal ob gerade ein eine kleine Datei eingelesen werden muss. Die größere Datei wird somit erst weggeschrieben und hat keine Chance im Cache zu landen. Das hat doch nichts damit zu tun das die interne Hardware der 1618+ die Geschwindigkeit nicht bereitstellen kann.

Ich muss sagen, dass ich nun mit meinem Latein am Ende bin.

 

[dil88]

Wahnsinn, was die sich so alles aus den Fingern saugen. Wozu gibt es die Option, wenn sogar die durchaus performante 1618+ davon nicht profitieren soll?

 

[MucMario]

danke für die antwort-weitergabe.

es ist schon ein witz, grenzwertig zur totalen kundenverarsche:

da werden einem geräte mit einem cache verkauft und die damit verbundene leistungssteigerung angepriesen, und wenn er dann nicht geht (den bock haben sicher beide hersteller geschossen), dann ist er auf einmal "unnötig"? unspürbar?

ja wahnsinn. bestätigt nur meine entscheidung, einen anderen hersteller zu ordern (kommt morgen).

und zur performance, nur mal so eine beobachtung: seit geraumer zeit brauchen selbst kleinste backups (TM) von 200-1000MB über eine halbe stunde! die dinger rödeln wie verrückt.

das hat damit zu tun, daß ohne cache auch kein NCQ geht usw., das heisst alle optimierungsmaßnahmen zur geschwindigkeitssteigerung sind damit ausser kraft gesetzt. ausserdem sorgen die nun nicht mehr optimierten zugriffe für erhöhte kopfarbeit (ha) und reduzieren damit die potentielle lebensdauer der geräte.

summa summarum: unfassbar.

 

[peterhoffmann]

Ich frage mich gerade, ob bei so viel Bullshit der Mitarbeiter beim Synology-Support so eine dumme Nuss ist, das er wirklich glaubt, dass ihm diese Ausrede technikaffine Leute abnehmen oder man bei Synology und Seagate schon so verzweifelt ist. Ok, es könnte auch beides zutreffen.

Nach erweiterten Tests von uns als auch von Seagate selbst gibt es hier keine Performance-Einbußen, da dieser Festplattentyp eine höhere Geschwindigkeit in der Verarbeitung erreicht, als das Modell DS1618+ über die interne Hardware bereitstellen kann. Es entsteht daher in dieser Kombination keinerlei Nachteil bei deaktiviertem write cache; bzw Sie würden keinerlei Geschwindigkeitsvorteil haben wenn das write cache aktiviert wäre.

Nach erweiterten Tests von uns als Autohersteller als auch Motorenhersteller selbst gibt es hier keine Performance-Einbußen, da dieser Motortyp eine höhere Leistung erreicht, als das Automodell über die Räder bereitstellen kann. Es entsteht daher in dieser Kombination keinerlei Nachteil bei deaktiviertem Turbo/Kompressor; bzw Sie würden keinerlei Geschwindigkeitsvorteil haben wenn der Turbo/Kompressor aktiviert wäre.

 

[MucMario]

gerade darüber gestolpert; ich finde, aktiv bewerben kann man das eigentlich nicht mehr.