ubuntuusers.de

Hallo Zusammen,

meine neue HDD (SDA) ist viel langsamer als die alte HDD (war genauso eingebaut wie die aktuelle sda), obwohl neuer (moderner) und doppelt so groß. Alles läuft jedoch ohne bisher festgestellte Fehler (sprich Datenverlust), eben nur sehr lahm (48 MB/s via dd gegenüber 148 MB/s die alte welche nun gerade als externe (Backup) HDD via USB angeschlossen ist). Weiter unten wie ich gemessen habe...

Ich habe drei Platten im PC.

• 1TB SSD (sdc) für System und Home.

• 1TB SSD (sdb) für für aktuelle Daten (Fotos, Musik und VMs).

• 16 TB HDD (sda) für Daten (finale Fotos und Videos).

Alles ist ext4 formatiert, alles nur Linux (kein Dualboot).

Aufgefallen ist mir das ehrlich gesagt erst gestern, als ich mit restric (sehr schnelles Backupprogramm für die console) feststellen musste, dass es sehr lahm läuft, Daten von der neuen HDD (sda) auf die alte HDD (an USB) zu sichern, was nur mit weniger al 9 MB/s noch ca. 200 Stunden gebraucht hätte.

An meinem PC kann es nicht generell liegen, denn Tags zuvor hatte ich noch mit einer anderen externen Platte (2 TB) mein System (sdc) in ca. 1,5 Stunden (fast 1 TB) mit Clonezille (vom Stick) gesichert. Als ich das Problem feststellte hatte ich die externe (alte) HDD im Verdacht und machte da ein Test mit dd (//wiki.ubuntuusers.de/Festplatten-Geschwindigkeitstest/:. Ich kam da auf 144 MB/s schreiben. Das ist zwar kein Spitzenwert, jedoch viel mehr als 9MB/s und auch für meine Zwecke ausreichend.

Dann lies ich dd auf die neue Platte (sda) los und war erstaut, nur 48 MB/s.

Das Problem ist nun, das ich keine aktuelle Sicherung von sda habe.... ☹

Hat jemand eine Idee, wie ich dem Problem (ohne Datenverlust) zu Leibe rücken kann?

Viele Grüße, Ralf

Zunächst mal vernünftige Tests machen. Dazu Laufwerke aka "gnome-disk-utility" nehmen. Anwendungsdaten sind keine sicheren Werte, bei dd hängt z.B. viel von der Blockgröße ab.

Beim Schreiben sind übrigens HDDs mit SMR Verfahren immer langsamer als normale Modelle! Bei 16 TB tippe ich stark auf SMR.

voxxell99 schrieb:

Zunächst mal vernünftige Tests machen. Dazu Laufwerke aka "gnome-disk-utility" nehmen. Anwendungsdaten sind keine sicheren Werte, bei dd hängt z.B. viel von der Blockgröße ab.

Beim Schreiben sind übrigens HDDs mit SMR Verfahren immer langsamer als normale Modelle! Bei 16 TB tippe ich stark auf SMR.

Danke für Dein Feedback. Ich habe das Disk-Tool installiert und dann damit Benchmarks gemacht. Das Ergebnis ist in der Tat ein ganz anderes, als das von dd. Hier ist die neue HDD ungefähr gleich auf mit der alten Disk, welche ich jetzt allerdings am USB-Port hängen habe. Das scheint jedoch nicht der Flaschenhals zu sein.

Soweit ich das ohne belastbares Hintergrundwissen bewerten kann, sieht das gar nicht mal so schlecht aus. Beide Platten scheinen so zu laufen wie sie sollen....

Ich habe vier Screenshots gemacht. Jeweils HDD-Eckdaten der alten 8TB (USB) und der neuen 18TB (sda) und jeweils die Benchmark Ergebnisse.

Um so mehr brennt mir nun die Frage unter den Nägeln, was ich tun kann damit es in der Praxis (jenseits der Benchmarks) wieder flotter läuft...

Grüße, Ralf

Hallo kunovwd

Spezifikation der HDD im Netz ermittelt wegen SMR und wie sieht dies für den USB Port aus?

Gruss Lidux

kunovwd schrieb:

[…] * 16 TB HDD (sda)

Vermutlich verwendet diese Platte SMR (lies die technische Spezifikation bzw. befrage den Hersteller). Diese Platten haben einen On-Disk-Cache, der CMR verwendet und damit vergleichbar schnell wie CMR-Platten ist. Sobald dieser vollgeschrieben ist, muss die Platte die Daten an den endgültigen Platz kopieren. Das dauert. in dieser Zeit können keine weiteren Daten auf die Platte geschrieben werden. SMR-Platten sind daher prinzipbedingt langsam beim Schreiben großer Datenmengen.

Lidux schrieb:

Hallo kunovwd

Spezifikation der HDD im Netz ermittelt wegen SMR und wie sieht dies für den USB Port aus?

Gruss Lidux

Hallo Lidux,

danke für Dein Feedback und den roten Faden.

Die Unterschiede zwischen CMR und SMR waren mir gar nicht bewusst und ich gebe zu, dass ich beim Kauf darauf entsprechend auch nicht geachtet habe ☹ Ob mein USB das kann oder nicht, kann ich gar nicht beantworten, weil ich nichts darüber gefunden habe, außer dass man auf jeden Fall SMR tunlichst vermeiden sollte. Allerdings wird SMR immer mehr zum neuen Standard wenn ich den gelesenen Artikeln glauben schenke.

Die Frage die sich jetzt stellt ist, ob ich noch was machen kann (spezielle USB-Ports einbauen, Treiberupdates o. ä.?) um auch mit SMR Platten ein glückliches Linux-Leben leben kann oder ich die Backug-Platte wegwerfen und sie durch eine CMR ersetzen muss?

Grüße, Ralf

kB schrieb:

kunovwd schrieb:

[…] * 16 TB HDD (sda)

Vermutlich verwendet diese Platte SMR (lies die technische Spezifikation bzw. befrage den Hersteller). Diese Platten haben einen On-Disk-Cache, der CMR verwendet und damit vergleichbar schnell wie CMR-Platten ist. Sobald dieser vollgeschrieben ist, muss die Platte die Daten an den endgültigen Platz kopieren. Das dauert. in dieser Zeit können keine weiteren Daten auf die Platte geschrieben werden. SMR-Platten sind daher prinzipbedingt langsam beim Schreiben großer Datenmengen.

Ja, dass scheint ein Problem zu sein, jedoch sind die Platten intern nicht so lahm, wie bei dem besagten Backup Job, bzw. fällt es nicht so auf, weil ich ja nur immer etwas schreibe und das gecached wird etc.. Die Frage bleibt, muss eine andere Platte her oder kann ich mich auch SMR-mässig anpassen (Treiber, andere USB-Ports, anderes externes Gehäuse, etc.)?

Grüße, Ralf

SMR ist SMR, da kannst nix dran drehen, das ist die interne Aufzeichnungstechnik. Bei so großen Kapazitäten ist das momentan Stand der Technik. Als Datengrab völlig okay, nur halt nicht optimal als Systemplatte, aber das nutzt du ja auch nicht so.

voxxell99 schrieb:

SMR ist SMR, da kannst nix dran drehen, das ist die interne Aufzeichnungstechnik. Bei so großen Kapazitäten ist das momentan Stand der Technik. Als Datengrab völlig okay, nur halt nicht optimal als Systemplatte, aber das nutzt du ja auch nicht so.

ja, dass habe ich gelesen, dass SMR langsamer ist als CMR HDDs, jedoch stand da jedoch nirgends, dass es um Faktor 10 (und mehr) langsamer ist. Doppelte (oder dreifache) Laufzeiten sind noch verkraftbar, aber 15 Tage nonstop um 6,5 TB zu sichern kann ja nicht sein.... oder? Irgendwas muss da noch gehen. Vielleicht die Blockgrößen beim (neuen) Einrichten der HDD auf einen anderen Wert setzen oder so?

Die um Faktor 10 zu geringe Geschwindigkeit liegt nicht an SMR, denke ich. Die Tests sehen ja völlig OK aus.

voxxell99 schrieb:

Die um Faktor 10 zu geringe Geschwindigkeit liegt nicht an SMR, denke ich. Die Tests sehen ja völlig OK aus.

Ja, dass habe ich eben auch schon mit einem anderen Backup Programm bei einem Test festgestellt. Das macht bisher (läuft noch) 127 MB/s (hat bereits 230 GB in 30 Minuten kopiert). Ein komplett akzeptabler Wert für meine Zwecke. Warum das restic so lahm ist; obwohl es in einem anderen Kontext echt schnell ist; bleibt noch unklar....

Gruß, Ralf

PS: Ich muss das revidieren, denn jetzt ca. 2 Stunden später bricht auch dieser Job gnadenlos ein, nun nur noch ein Schnitt von knapp über 60 MB/s mit stark abnehmender Tendenz. ☹ Es sind alles Fotos, unterschiedlich große JPGs (je älter, desto kleiner) und Raw-Files die größer sind als die JPGs. Ich guck mal was morgen früh angezeigt wird... So ein Mist...

voxxell99 schrieb:

Die um Faktor 10 zu geringe Geschwindigkeit liegt nicht an SMR, denke ich. Die Tests sehen ja völlig OK aus.

Doch, das scheint tatsächlich an SMR zu liegen. ☹ 10-20 mal langsamer als CMR lese ich auf diversen Seiten ....

Die Tests sehen deswegen okay aus, weil es am Anfang recht schnell (durch die Cache Technik?) geht, "nachher" bricht die Transferrate extrem ein. Mein Test gestern Abend mit FreeFileSync zeigt dies auch.... erst ging es gut ab mit bis zu 250 MB/s, dann einen Schnitt von immer noch 170 MB/s nach 30 Minuten und heute Morgen dümpelte er mit 5-30 MB/s rum (der Schnitt war da nach 9 Stunden auf 30 MB/s (Tendenz weiter sinkend) gesunken. Ich habe abgebrochen, denn er sagte 5 Tage (für ~ 3TB Fotos) voraus...

So wie das aussieht habe ich tatsächlich das Geld zum Fenster raus geschmissen... ☹

Gruß, Ralf

Du solltest das hier schreiben, wenn du woanders auch einen Thread zum Thema laufen hast: https://forum.restic.net/t/restic-first-backup-very-slowly/5289

Ubunux schrieb:

Du solltest das hier schreiben, wenn du woanders auch einen Thread zum Thema laufen hast: https://forum.restic.net/t/restic-first-backup-very-slowly/5289

Naja, ich sah das als zwei unterschiedliche Fragen. Im restic Forum frage ich danach ob es einen (undokumentierten) Programm-Parameter geben könnte, der das Problem mildert und hier frage ich danach, ob es etwas auf Systemebene geben könnte, was das SMR-Problem allgemein "verbessern" kann.

Es scheint weder das eine noch das andere möglich, sprich für mein Ziel ein Backup auf eine externe (USB)Platte in akzeptabler Zeit zu machen, ist scheinbar mit SMR HDDs nicht möglich ☹

Ich werde das jedoch noch testen mit dem Anpassen der Parameter in restic, sobald ich dazu komme und berichte natürlich auch hier, WENN das was bringen sollte. ☺

Gruß, Ralf

Es sind alles Fotos, unterschiedlich große JPGs (je älter, desto kleiner) und Raw-Files die größer sind als die JPGs.

Bei vielen kleinen Dateien brechen Kopiervorgänge immer stark ein, das ist völlig normal, wenn dateiweise kopiert wird. Dabei wird nie die Transferrate für kontinuierliche Datenströme erreicht! Wenn du nicht Äpfel mit Birnen vergleichen willst, solltest du zur Beurteilung nur auf professionelle Tests zurückgreifen und nicht irgendwelche Forenmeinungen.