Raid Rebuild zu langsam ..

[Shadowblues]

Hallo zusammen,

vielleicht habt ihr eine Idee was ich anpasen muss damit es schneller wird:

Ich habe eine 1815+ Kiste mit 2x 240GB SSD und 3x8TB SSD (Seagate Archive HDDs). Nun ist eine der Platten ausgefallen, ich wurde von Seagate über SMR belehrt und habe mir eine Seagate IronWolf zum Austausch besorgt. Damit läuft aktuell der Raid Rebuild.

Dieser ist jetzt in der Phase "Prüfung der Konsistenz" und ist bei 65% -> und das nach 7! Tagen.

Alle Performancewerte sind minimal - CPU, RAM, Disk-I/O, Auslastungen,...

In der Prüfungsphase sollte er doch nur die bestehenden 13TB Daten einlesen und mal "drüberschauen". Sollte alles mit voller Performance laufen und auch durch SMR nicht beeinträchtigt werden. Ein späterer Aufbau der neuen Platte sollte auch durch das SMR der Archive HDDs nicht beeinträchtigt werden - es wird ja von diesen Platten nur gelesen ..

Wie kann ich das beschleunigen - oder aber - wo ist das Bottleneck?

Gruß
Roger

 

[Fusion]

SSD <-> Seagate Archive HDDs ? Du meinst sicher auch vorne 8TB HDD, SSD wäre ja fast unbezahlbar mit 8TB.

Bin mir nicht sicher was unter "Prüfung der Konsistenz" fällt, aber vielleicht eben doch die XOR Redundanz-Erstellung auf der neuen Platte.

Aber jetzt noch 3 Tage warten, oder mit anderen Einstellungen eventuell neu anfangen, da wirst nichts mehr groß sparen. Das würde ich jetzt auch noch voll durchstehen.

Bischen Lesestoff
https://forum.synology.com/enu/viewtopic.php?t=65730
http://taste-of-it.de/linux-raid-resync-und-rebuild-beschleunigen/

 

[Puppetmaster]

SSD <-> Seagate Archive HDDs ? Du meinst sicher auch vorne 8TB HDD, SSD wäre ja fast unbezahlbar mit 8TB.

?

Ich habe eine 1815+ Kiste mit 2x 240GB SSD und 3x8TB SSD

Was liest du denn da?


"Prüfung der Konsistenz" der Platte heißt m.E., dass die Platte einmal komplett durchgetestet (also beschrieben und ausgelesen) wird, bevor es weitergeht. Das kann man ja auch bei Basis-Volumes haben, ohne RAID.
Dass die Archive-HDD bei sowas am Limit ist, sollte aufgrund von SMR dann auch klar sein. Von daher kann ich mir deutlich längere Zeiten schon vorstellen. Ob nun 7-10Tage realistisch sind, weiß ich nicht. Aber es gibt schon einen Grund, weshalb SMR-Platten nicht für ein RAID >1 verwendet werden sollten.

EDIT: LOL, jetzt sehe ich es auch ... 8TB SSD ... sehr gut. In der Klammer dahinter wird's aber dann ja auch aufgelöst.

 

[Shadowblues]

Hallo Fusion, es sind natürlich 8TB HDDs, nicht SSDs

Zu Deinen Links: Hatte natürlich schon einiges gelesen - aber bei manchen bringen die Änderungen der Werte was, bei manchen nicht und bei anderen bricht der Rebuild auch ganz ab. Ich würde ungern meine Daten verlieren ..
Klar hab ich n Backup .. aber das braucht auch länger bis das zurück ist ..

Aber es kann doch nicht sein, dass Synology auf so alten Limits festsitzt? Ausserdem ist das hochkarätig gefährlich was hier passiert. Jedes richtige Raid hat 2 Optionen: Rebuild mit Full Speed um möglichst schnell sicher zu werden - dann sind halt die User die mit den Gescheindigkeitseinschränkungen oder aber Rebuild in der Wartezeit - dann nutzt der Server die nicht von Usern belegte Zeit zum Rebuild aus.

Aber dass ein Server die Zeit lieber mit Idle verstreichen lässt als den Rebuild voranzutreiben, das habe ich ja noch nie gesehen.

Gruß
Roger

 

[Fusion]

Synology ist für so einiges gut, was ich vorher noch nie gesehen habe.

Ich habe leider auch keine Vergleichszahlen für RAID-5 mit SMR drives parat.
Hast du mal im Resourcen-Monitor oder eventuell mit iotop nachgesehen, was die IO Last so sagt, wenn es offensichtlich nicht die CPU Last ist?
Wobei du ja meintest du hättest das schon angesehen. mmmh.

 

[dil88]

@Shadowblues: Wir können hier in diesem Punkt sicherlich schnell Einigkeit herstellen, nur wird sich dadurch nichts ändern. Dafür müsstest Du Dich an Synology wenden.

Die proc-Parameter zur Rebuild-Speed kannst Du m.W. ohne Sorge ändern, da raucht nichts ab.

 

[Shadowblues]

Hallo zusammen, also nen Call bei Synology ist dazu offen .. aber wie ich die kenne, melden die sich in x Wochen hierzu. Aber da ich diesen Tausch ja noch zweimal machen muss um die SMR Drives da komplett rauszunehmen, werde ich damit wohl noch 1-2 Monate beschaeftigt sein .. Und alles ohne Redundanz und mit viel zittern. Das war genau der Grund wieso ich mir ein NAS mit redundanten Platten gekauft habe ...

 

[dil88]

Mit Backup wäre Neuaufsetzen wesentlich schneller. War Dir beim Kauf der Archives nicht klar, dass SMR-Platten im RAID-5 nicht wirklich Freude machen?

 

[Shadowblues]

Naja, ich habe ehrlich gesagt nicht viel nachgelesen .. Archive HDD, 5400 rpm .. --> Ok, sind halt etwas langsamere Platten aber so die Performace brauch ich ja nicht, durch den SSD Puffer gehts ja trotzdem schnell ..

So war meine Überlegung. Dass Seagate hier mit SMR rumspielt und es nicht draufschreibt, das hätte ich nicht gedacht.

 

[Frogman]

...Dass Seagate hier mit SMR rumspielt und es nicht draufschreibt, das hätte ich nicht gedacht.

Sorry, aber ich halte es für ziemlich blauäugig, einfach eine Platte zu kaufen, ohne sich mit den Spezifikationen zu beschäftigen, um sich danach über mangelnde Schnelligkeit zu beschweren. Hier im Forum gibt's zur Archiv eine umfängliche Diskussion, und auch ein einziger Blick in die Beschreibung der Platte - ob in den Shops oder direkt bei Seagate - offenbart die SMR-Technik.

 

[Shadowblues]

Ja, hätte, könnte, sollte ... alles in Ordnung. Wie Du aber siehst beschwere ich mich nicht über die Performance der Platte sondern akzeptiere meinen Fehler und wechsle die Platten nun aus. Das mal zu Deiner Unterstellung. Ich frage nach der absolut grottigen Performance eines unbelasteten NAS in dem Rebuild Prozess und dem Grund hierzu - und wie man es evtl. umgehen kann.

Ich freue mich aber, dass Du so viel Zeit hast, dass Du zu jedem technischem Gerät welches Du in Deinem Leben kaufst auch alle Spezifikationen und Forenbeiträge durchliest, Dich in Fachartikel reinarbeitest und dann aufgrund einer fundierten Pro / Kontra Liste Deine Entscheidung triffst. ICH habe die Zeit dazu NICHT. Leider.

So long,
Roger

 

[Frogman]

...Das mal zu Deiner Unterstellung. Ich frage nach der absolut grottigen Performance eines unbelasteten NAS in dem Rebuild Prozess und dem Grund hierzu - und wie man es evtl. umgehen kann.

Ich unterstelle Dir nichts - Du schreibst selbst, Du hättest nicht viel geschaut. Und bemängelt habe ich den Vorwurf, Seagate würde "hier mit SMB herumspielen und es nicht drauschreiben".

...Ich freue mich aber, dass Du so viel Zeit hast, dass Du zu jedem technischem Gerät welches Du in Deinem Leben kaufst auch alle Spezifikationen und Forenbeiträge durchliest, Dich in Fachartikel reinarbeitest und dann aufgrund einer fundierten Pro / Kontra Liste Deine Entscheidung triffst.

Das freut mich auch - wenngleich ich mir dafür auch bewußt Zeit nehme, um um dann nicht wie der Ochs vor'm Berg zu stehen.

ICH habe die Zeit dazu NICHT. Leider.

Tut mir leid für Dich.

 

[Shadowblues]

Ich würde hier:

http://www.seagate.com/de/de/enterprise-storage/hard-disk-drives/archive-hdd/

mindestens erwarten, dass Seagate eine Warnung ausspricht und erklärt wieso die Platte NICHT für den Desktopbetrieb und noch weniger für RAID geeignet ist. Stimmt, hier steht was von SMR - aber man kann nicht erwarten dass jeder Kunde gleich die Auswirkungen versteht.

EDIT: Prüfe die Konsistenz der Parität war gestern auf >75%. Jetzt steht da plötzlich 11,47% ... WTF?

Gruß
Roger

 

[Puppetmaster]

Hast du da mal auf das Datenblatt geklickt? Da steht's auf der ersten Seite schon drin. Zwar als Fußnote, aber wie ich finde, recht deutlich formuliert. Inkl. der zu erwartenden Performanceeinbußen.

 

[Puppetmaster]

EDIT: Prüfe die Konsistenz der Parität war gestern auf >75%. Jetzt steht da plötzlich 11,47% ... WTF?

Ich sagte es doch bereits: die neue Platte wird beschrieben und gelesen. Da sie drei Partitionen hat, wird die große Partition inzwischen durch sein, und jetzt kommen System- und SWAP-Partiton an die Reihe.

 

[Shadowblues]

Hmmmm...

das wäre aber inkonsistent ... hier wird ja explizit Volume 1 angezeigt ...
Aber gut, wenns so wäre, dann ists halt so ...
Aber trotzdem: 7 Tage um von 0 auf 75% zu kommen und dann 12 Stunden später im nächsten? Job bei 11% zu stehen - das ist komisch.
Und nein, Datenblatt hatte ich nicht gelesen ... das muss besser sichtbar sein ...

Gruß
Roger

 

[Puppetmaster]

Aber trotzdem: 7 Tage um von 0 auf 75% zu kommen und dann 12 Stunden später im nächsten? Job bei 11% zu stehen - das ist komisch.

Warum? Die Datenpartition ist bei 8TB Rohkapazität vielleicht 7,8TB groß, die Systempartition 200GB und der SWAP sehr klein.
Das passt schon.

Und nein, Datenblatt hatte ich nicht gelesen ... das muss besser sichtbar sein ...

Sehe ich anders. Hab's in weniger als 30s gefunden. Das Datenblatt gucke ich mir doch ohnenhin an, der Rest ist schließlich nur der Marketing-Schwampf.

 

[Shadowblues]

Hallo, nein - das passt nicht. Wenn das Teil in 7d nur ca. 75% schafft, dann schafft es ca. 11% / 24h. Die letzten 25% konnten also rechnerisch nicht in 12h abgedeckt werden, es wären ca. 30h dafür notwendig gewesen. Egal, im Durchnitt der ersten 75% wären das also ca. 2TB / d. Die 200GB Swapdatei muessten also in ca. 1/10 d abgehandelt werden. Real hat er nach 4h grade mal 8% geschafft.
Fazit: Keine Ahnung was das Teil macht, die Zahlen sind auf jeden Fall inkonsistent.

 

[Puppetmaster]

Vielleicht läuft es bei einer SMR Platte eben auch nicht linear.

Auch noch denkbar wären natürlich Fehler auf der Platte.

 

[Frogman]

Es läuft nicht-linear auf einer SMR-Platte, aufgrund der asymmetrischen Pufferbereiche.