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

[Archi_74]

Es ist mir auch absolut unverständlich warum hier im Forum auf der Startseite und anderweitig trotz eindeutiger Probleme mit dem Schreibcache noch die Werbetrommel gerührt wird.
Es mag ja sein das Seagate mit den Ironwolf das fortschrittlichste 14 TB Datenspeicher-Portfolio der Branche hat, aber momentan haben eben diese in Verbindung mit Synos Probleme.

Auch wenn ich nicht wirklich intensiv recherchiert habe, tippe ich persönlich fehlerseitig inzwischen auf Synology und nicht Seagate. Bis jetzt ist mir z.B. bei QNAP nichts zu Ohren gekommen.

 

[peterhoffmann]

Er (seagate_surfer) hat mir gerade eine PN geschickt, wo er mitteilt, dass ihm die lange Wartezeit leid tut, er die Fragen weitergeleitet hat und diese so schnell wie möglich beantworten will.

Tja, das war vor einer Woche. Bisher kein Feedback.

Ich habe mich mit meiner Meinung zu Seagate bisher zurückgehalten. Aber sorry, nu muss es auch mal raus. Ich hatte früher viel im Bereich Hardware und Datenrettung zu tun. Statistiken haben wir zwar nie geführt, aber Seagate war (gefühlt zu) oft vertreten. Ich selber mache seit über 20 Jahren einen Bogen um Seagate. Hier im Forum hat einer den Spruch schon gebracht: "Seagate oder Seagate nicht" (laut aussprechen).

Es gibt auch keinen perfekten Hersteller (leider). Größere Probleme mit Serien hatte jeder mal. Man weiß es nie vorher und kauft immer die Katze im Sack. Die Frage ist aber, wie man damit umgeht und für Lösungen sorgt.

Wenn ich hier lese, wie Seagate die Leute für saudumm verkauft ("deaktivierter Cache wird durch die hohe Performance kompensiert"), der schwarze Peter zwischen Synology und Seagate hin- und hergeschoben wird und am Ende alle sich tot stellen, wird mir kotzübel. Und das bei den großen HDDs, die 300 Euro und mehr kosten, sprich da, wo Kohle verdient wird. Nein, danke, Seagate, ich werde euch auch die nächsten 20 Jahre nicht kaufen. Und danach brauche ich euch auch nicht mehr, weil ich dann das Zeitliche segne.

Ist hier keiner im QNAP-Forum unterwegs? Gibt es da auch Cacheprobleme?

 

[MucMario]

Salut,

ich poste das zur Info für die Interessierten; ich selbst bin durch Wechsel der Platten nicht mehr betroffen.

Synology schrieb mir:

"...leider kam es im Verlauf der Bearbeitung Ihrer Anfrage zu einigen Mißverständnissen.
Bei den von Ihnen verwendeten Festplatten besteht ein Kompatibilitätsproblem zwischen den HDDs und der verwendeten Hardware. Es handelt sich daher weder um einen direkten Fehler an der Festplatte, noch um einen direkten Fehler an der Hardware an sich. In der Kombination beider Produkte und aktivem Cache besteht die Möglichkeit, daß es zu Timeouts beim Datenzugriff kommt. Bei deaktiviertem Cache dieser Festplatten tritt das Verhalten nicht auf.
Nach internen Tests von uns als auch vom Hersteller der Festplatten ist die Zugriffs- und Übertragungsgeschwindigkeit der Festplatten auch bei deaktiviertem Cache höher als es die verwendete Hardware zur Verfügung stellen kann. Ein aktivierter Cache würde demnach in dieser Kombination keinerlei Geschwindigkeitsvorteil bringen."

Jeder bilde sich sein eigenes Urteil.

Mein Fazit: Trotz mehrfacher Versuche wird hier nur beschwichtigt und der versierte Kunde wird veralbert. Es werden keine nachvollziehbaren Fakten geliefert, sondern pauschal "viel zu schnell für die HW Ihres NAS". Das ist - sorry - Kundenverarsche. Nebenbei: Warum sollte man dann überhaupt noch Cache in die Platten einbauen, wenn der eh nichts bringt? Kann man nur mit der Stirn runzeln.

Quintessenz: Weder Synology noch Seagate haben sich professionell verhalten, schade ist das. Mich ärgert's immer noch.

Servus!

 

[Matthieu]

Wie würde denn ein passendes Testverfahren aussehen? Da ich nicht betroffen bin, könnte ich mit ab- und anschalten des Cache das ganze einfach durchtesten.
Wem fällt ein passendes Tool für die IO-Performance ein? Übers Netz testen macht keinen Sinn, weil man damit die Platten nicht ausgereizt bekommt.

MfG Matthieu

 

[AndiHeitzer]

Wem fällt ein passendes Tool für die IO-Performance ein?

Kurze Suche ergab mir folgendes:
https://www.pablo-bloggt.de/linux/stresstest-hardwarecheck-unter-linux/

 

[Matthieu]

Das ist aber verdammt aufwändig. Das müsste man für die DSen erst compilen ... Ich dachte jemand hat vielleicht Ideen zu was vorhandenem.

MfG Matthieu

 

[BigRonin]

Das ist aber verdammt aufwändig. Das müsste man für die DSen erst compilen ... Ich dachte jemand hat vielleicht Ideen zu was vorhandenem.

MfG Matthieu

Sorry für Vollzitat ... auf dem Handy ist das umständlich

Wenn du das wirklich mal testen möchtest ... versuche mein Tool „AvrLogger“ ... einmal mit Cache und dann ohne Cache. Die Schreib- / Lesewerte kann man testen in dem du auf einem Volumen mal die Datenbereinigung anstößt.

 

[Matthieu]

Hallo,
das ist aber alles etwas am Ziel vorbei in meinen Augen. Ich sehe vergleichbare Werte nur gewährleistet wenn man wiederholt bestimmte Operationen durchführt die möglichst praxisnah sind. Eine Datenbereinigung sollte mit jedem Durchlauf etwas schneller werden bis zu einem gewissen Punkt, weil er jedes Mal weniger bereinigt. Außerdem stellt das keinen Bezug zu Alltagsrelevanten Prozessen dar.

Kennt jemand eine io-lastige Alltagsaufgabe für eine DS die sich idealerweise noch über die CLI automatisieren lässt?

MfG Matthieu

 

[nosxxx]

Ich kann bestätigen das ich bei 5 ST12000VN0007 keinen Write Cache habe.
Trotzdem steht die HDD noch auf der Kompatibilitätsliste.

Wisst ihr da inzwischen mehr?

Wie kritisch ist das eurer Meinung nach? Ich habe die Platte im Raid 6 und brauche die Mehrleistung eigentlich nicht.

 

[Fusion]

@Matthieu - wie wäre es mit einfachen I/O-tests für den Anfang mit hdparm. Einfach um mal den Einfluß bzw ein Gefühl dafür zu bekommen. Ich hab leider gerade keine Ersatzplatte die ich mal an einem externen Linux testen könnte mit/ohne Write-Cache. Könnte maximal Werte für die 10TB Ironwolf im Zustand mit deaktiviertem Cache liefern.

https://www.thomas-krenn.com/de/wiki/Linux_I/O_Performance_Tests_mit_dd
https://www.thomas-krenn.com/de/wiki/Cache_Einstellungen_von_RAID_Controllern_und_Festplatten

Synology deaktiviert den Linux Write Cache mit hdparm

hotplugd: hotplugd.c:1451 ==== SATA disk [sdc] hotswap [add] ====
hotplugd: disk/disk_config_single.c:293 apply /usr/syno/bin/DiskApmSet.sh 255  /dev/sdc 1>/dev/null 2>&1
hotplugd: disk/disk_config_single.c:293 apply /usr/syno/bin/syno_disk_ctl --ncq-on  /dev/sdc 1>/dev/null 2>&1
hotplugd: disk/disk_config_single.c:293 apply /usr/bin/hdparm -W 0  /dev/sdc 1>/dev/null 2>&1
hotplugd: disk/disk_config_single.c:264 /dev/sdc apply EPC off
kernel: [  215.540764] sd 0:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
hotplugd: hotplugd.c:1472 ==== SATA disk [sdc] Model: [ST10000VN0004-1ZD101    ] ====

Mag sein, dass man mit RAID-Kombis es teilweise nicht merkt, wenn man den Falschenhals gigabit LAN betrachtet, aber bei copy/move von einer auf die andere Platte oder innerhalb einer Platte kann ich mir ums Verrecken nicht vorstellen, dass dies keinen (signifikanten) Einfluß auf die Performance hat.
Da ich von Seagate ober bei den aktuellen Kernel-Changelogs nichts in die Richtung gesehen habe (kanns natürlich auch verpasst oder übersehen haben...) frage ich mich, ob es mit dem veralteten Linux-kernel und der Backport Patcherei irgendwas zu tun hat, oder der alte Kernel eventuell selber ein Problem mit dem Cache hat. Habe ich noch nicht weiter recherchiert in die Richtung.

 

[ruedi66]

Das liegt garantiert am (alten) Kernel. Im Jahr 2015 gab es schonmal solche Probleme mit Seagate. War damals die ST8000AS0002 (8TB). Die Lösung war ein Kernel Patch. Mittlerweile habe ich persönlich aber alle Seagates weggeworfen und auf WD gesetzt. Seagate und Linux ist halt so eine Sache....
Cache Back deaktivieren bedeutet definitiv mehr I/O auf der HDD, das ist keine saubere Lösung von Synology.

Edit: link von damals
https://bugzilla.kernel.org/show_bug.cgi?id=93581

 

[nosxxx]

Ich finde es ja dreist das die von Synology die Platten einfach nicht mehr unterstützen wollen. HardwareInkompatibilität das ich nicht lache. Funktioniert denn die ST12000NE007 noch?

 

[solip90]

Ich kann bestätigen das ich bei 5 ST12000VN0007 keinen Write Cache habe.
Trotzdem steht die HDD noch auf der Kompatibilitätsliste.
Wisst ihr da inzwischen mehr?

Ich sah heute das wohl alle Ironwolf 10 TB und größer keinen Cache mehr haben bei Synology.

Das ist natürlich ganz große Klasse alldiweil die ausdrücklich auf der Kompatibilitätsliste stehen ohne irgendeine Anmerkung dazu.

Wie kritisch ist das eurer Meinung nach? Ich habe die Platte im Raid 6 und brauche die Mehrleistung eigentlich nicht.

Absolut kritisch. Kein Cache, kein NCQ... wenn das NAS was zu tun hat, dann rattern die sich zu Tode und alles dauert ewig.

 

[Strotch]

Ich finde es ja dreist das die von Synology die Platten einfach nicht mehr unterstützen wollen. HardwareInkompatibilität das ich nicht lache. Funktioniert denn die ST12000NE007 noch?

Ja, die funktioniert aktuell noch mit aktivem Schreibcache.

Ich sah heute das wohl alle Ironwolf 10 TB und größer keinen Cache mehr haben bei Synology.

für die 12TB IW-Pro ist die Aussage nicht zutreffend, da Cache aktuell noch aktiv. Wie es bei der 14TB aussieht, kann ich nicht sagen...

 

[peterhoffmann]

Ich hatte Ende November 2018 den User seagate_surfer (Mitarbeiter von Seagate) per PN angeschrieben und ihm auf diesen Thread hingewiesen. Er antworte am 6. Dezember per PN, dass er die Fragen bezüglich des Cacheproblems weiterleitet und diese so schnell wie möglich beantworten wird.

Trotz Nachfrage gibt es da seit fast 2 Monaten keinerlei Feedback, nicht per PN und auch nicht hier im Thread, geschweige eine Lösung.
Schnell heißt wohl bei Seagate => Ignorieren

Ja, so geht man mit Kunden um. Einfach totschweigen und dumm im Regen stehen lassen. So eine Platte kostet ja auch nur läppische 300 Euro aufwärts. Wenn ich lese, dass manche 10 Stück davon liegen haben, wird mir ganz schlecht.

Meine Meinung: Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende. Es gibt auch andere Mütter, die hübsche Töchter haben.

Posting v. 07.12.2018: https://www.synology-forum.de/showt...Update-1/page9&p=802405&viewfull=1#post802405
Posting v. 14.12.2018: https://www.synology-forum.de/showt...pdate-1/page11&p=803268&viewfull=1#post803268
Userprofil seagate_surfer: https://www.synology-forum.de/member.html?90153-seagate_surfer
Der User seagate_surfer war übrigens das letzte Mal am 14.01.2019 hier online.

 

[solip90]

Ich sehe das Problem eher bei Synology.

Wir verwenden hunderte Seagate Ironwolf. Hauptsächlich an richtigen RAID Controllern. Die Modelle mit He-Füllung sind aktuell wahrscheinlich das beste in der Preis-/Leistungsklasse. Natürlich gehen die Platten alle problemlos und bringen ihre Performance. Jeder Controller der 4k-fähig ist nimmt diese Platten so selbstverständlich wie jede andere auch.

So Sachen das Platten auf der Kompatibilitätsliste stehen und plötzlich eigentlich nicht mehr funktionieren gibt es woanders nicht. Sowas kenne ich nur von Synology. Und das scheint mir eher ein Problem von dem extrem umfangreichen DSM zu sein, wo alles + lauter Dienste auf ein simples Linux SoftRAID abgewickelt werden.

 

[Mercator]

Wie ist das eigentlich aktuell bei QNAP?

 

[Iarn]

Ich sehe das Problem eher bei Synology.

Nachdem beide Firmen mit ihrer Partnerschaft und dem angeblichen perfekt aufeinander abgestimmt angegeben haben wie Lothar Matthäus und Dieter Bohlen zusammen, sollen sie auch die Suppe gemeinsam auslöffeln.
Insbesondere der Werbe Account 'Seagate Surfer
'wurde meiner Meinhng nach hier als solcher entlarvt. Von all den Beteuerungen für Probleme etc da zu sein, etc bla Blubb keine Spur mehr.

 

[nosxxx]

Zum Glück hat Amazon die 5 Seagate Ironwolf 12TB ohne Mucken zurückgenommen. Habe mir dann um etwa 5-10 Euro mehr HUH721212ALE600 (Western Digital HC520) gekauft.
Laufen bisweilen super.

 

[BanditDD]

Hallo,

die Aufregung kann sich wieder legen! Die 10GB IronWolf ist nach einem Firmware-Update (neu: SC61) schreibcache-tauglich. Auch die Kompatibilitätsliste ist dahingehend aktualisiert worden. Kann für meine DS1618+ Erfolg vermelden!

Gruß,
BanditDD