ubuntuusers.de

Hallo,

ich habe an meinem PC eine externe USB3-Festplatte (ext4) hauptsächlich für Videos. Da sie mittlerweile zu klein geworden ist, besorgte ich mir eine neue (Intenso Memory Center 8TB).

Da exfat-formatiert, habe ich sie erst mal mit ext4 neu formatiert um die Videos von der zu klein gewordenen Platte auf die neue zu kopieren.

Der Kopiervorgang startete auch erst mal relativ flott mit ca. 120 MB/s, um dann immer langsamer zu werden. Nach ein paar Stunden waren gerade mal 500 GB kopiert. Laut Fenster "Dateivorgänge" wurde die Restzeit nicht geringer sondern hatte sich wieder erhöht. Minutenlang schien gar nichts kopiert zu werden um dann mal wieder ein paar hundert MB rüberzuschieben.

Hier habe ich dann abgebrochen, weitere zehn Stunden für die restlichen 3TB wollte ich dann doch nicht warten. Ich habe dann die Platte zum Ausprobieren (mit Windows) NTFS formatiert und dann nochmal mit dem Ubuntu-Rechner einen neuen Kopierversuch gestartet, aber die Ergebnisse waren ganz ähnlich.

Schließlich habe ich sie wieder mit exfat formatiert, und hiermit lief das Kopieren deutlich schneller. Exfat möchte ich eigentlich gar nicht haben. Woran liegt es, dass ext4 da so lahmt und exfat nicht?

Ich habe auch keine Ahnung, was für eine Platte da in dem Plastikgehäuse steckt, alles gut verklebt, auf der Verpackung sind auch keine Angaben.

Wie Kopierst du? Versuche es mal im Terminal →→ dd da kann man sich den Fortschritt auch anzeigen lassen.Alternativ →→ cp

Mit Ext4 hat das eher wenig zu tun – eher mit dem Speicher auf der USB Platte.

Wendelinchen schrieb:

Der Kopiervorgang startete auch erst mal relativ flott mit ca. 120 MB/s, um dann immer langsamer zu werden.

Logisch. Es wird nicht direkt kopiert, sondern erst in einen Cache.

Davon abgesehen, manche erwarten offenbar wahre Wunder von USB - und dann auch noch Intenso, "Qualität" aus der Schütte.

Im übrigen ist schon angedeutet worden, daß es nicht unwichtig ist, womit und mit welchen Settings kopiert werden soll.

Nimmt man bspw. DoubleCommander, hat der zwar insgesamt brauchbare Defaults, an einer entscheidenden Stelle patzt er jedoch. Aber im Gegensatz zu anderen Filemanagern kann man überhaupt etwas ändern. Für "Buffer size for file operations" sind nur 512 KiB eingestellt. Diese gewaltige Handbremse löst man mit Versechzehnfachung, also 8 MiB (ich habe vor längerer Zeit umfangreich mit verschiedenen Werten getestet). Dann geht's ab wie Schmidts Katze (natürlich im Rahmen dessen, was die Hardware hergibt).

von.wert schrieb:

und dann auch noch Intenso, "Qualität" aus der Schütte.

Irgendwer muss doch die Ausschuss der Festplattenhersteller kaufen. 😛

Langsam, langsam, ihr lasst ja kein gutes Haar an Intenso. Intenso stellt keine Festplatten her, sondern baut lediglich Festplatten namhafter Hersteller in ihre eigenen Gehäuse. Diese neue Platte ist meine vierte von Intenso, die anderen drei laufen schon seit Jahren problemlos; neben dem Preis ein Grund, dass ich mich wieder für Intenso entschieden habe. Und nein, ich habe keine Aktien von Intenso.

Kopiert habe ich mit Caja indem ich einfach die Dateien von einem Fenster ins andere gezogen habe. Dafür ist die grafische Oberfläche doch da, oder?

Wie ich schon schrieb, habe ich die Platte noch mal mit exfat formatiert und den Kopierprozess noch mal genauso gestartet, wie beim ersten mal und über Nacht laufen lassen. Als ich heute früh, nach über acht Stunden wieder nachsah, war das Kopieren "schon" fertig. Rechne ich mal mit 8,5 Stunden für 4,5 TB, komme ich auf knapp 150 MB/s. Das ist noch weit weg von den 500 MB/s, die USB3 angeblich schaffen soll, aber dieser (maximale) Wert gilt ohnehin nur unter optimalen Umständen, die in der Praxis nie vorkommen.

Da der einzige Unterschied bei den beiden Kopierversuchen das Dateisystem war, kann es ja mit Cachegrößen oder irgendwelchen Einstellungen irgendwo nichts mehr zu tun haben.

Meiner Meinung nach könnte es daran liegen, dass exfat kein Journal führt, ext4 und ntfs aber sehr wohl. Das Mitführen eines Journals würde eine etwas geringere Schreibgeschwindigkeit erklären, aber nicht den dramatischen Rückgang den ich festgestellt habe.

Möglicherweise handelt es sich bei der neuen Platte um eine SMR-Platte. Das wäre für mich eine Erklärung für ihr Verhalten, denn wenn das Journal ständig neu auf die Platte geschrieben werden muss, müssen eventuell die Dateien benachbarter Spuren woanders hin geschrieben werden an Stellen, wo auch wieder benachbarte Spuren...

Selbst wenn ich exfat weiter verwende, bedeutet das, dass der freigegebene Speicherplatz von gelöschten Dateien nicht neu verwendet werden kann, ohne die halbe Platte umzubauen. Im Lauf der Zeit würde ich also trotzdem mit einem dramatischen Leistungseinbruch rechnen müssen.

Meine Folgerung: Finger weg von SMR-Platten.

Kann man irgendwie rauskriegen, was da für eine Platte verbaut ist ohne das schöne Plastikgehäuse kaputt zu machen?

Kann man irgendwie rauskriegen, was da für eine Platte verbaut ist ohne das schöne Plastikgehäuse kaputt zu machen?

Oft siehst du mit smartctl / hdparm die Typenbezeichnung/Seriennummer der internen Platte.

Man muss inzwischen leider von SMR ausgehen, sofern nicht anders angegeben. Viele Festplattenhersteller haben ihre SMR-Platten verkauft ohne SMR drauf zu schreiben...

PS: bei Performanzproblemen trotzdem mal ins dmesg schielen

Vielen Dank an frostschutz, Dein Tipp war gut, die Platte ist eine Seagate Barracuda st8000dm004. Nicht unbedingt "Qualität aus der Schütte" und auch nicht "Ausschuss der Festplattenhersteller", oder? Laut Seagate Webseite ist ihr Aufzeichnungsverfahren wirklich SMR.

Neugierig geworden habe ich die zu ersetzende Platte (ebenfalls Intenso, aber im aufschraubbaren Metallgehäuse) mal aus ihrem Gehäuse ausgebaut: Auch eine Seagate Barracuda, nur 5TB groß (st5000dm004), aber auch mit SMR.

Warum ist mir bei ihr ein solches Verhalten nie aufgefallen?

Weil ich nie so große Datenmengen auf einmal auf sie geschoben habe, sondern immer nur mal eine Handvoll Videos auf einen Schlag? Sie läuft mindestens zehn Stunden am Tag, wird aber nur selten benutzt, hat also jede Menge Zeit sich neu zu organisieren.

Da habe ich wohl zu laut auf SMR geschimpft, ich werde die Platte wohl doch nicht zurückschicken.

Ok, jetzt habe ich zwar alle Videos auf der neuen Platte, aber exfat gefällt mir gar nicht. Umwandeln wie früher mal FAT auf NTFS geht wohl nicht. Ich fürchte, wenn ich jetzt

1

sudo dd if=/dev/alt of=/dev/neu status=progress bs=1M

versuche, ist mein Rechner tagelang am rödeln. Aber ich hoffe, wenn dd block zu block kopiert, also unabhängig vom Dateisystem, wird ja wohl auch kein Umorganisieren während des Kopierens oder ein Zugriff zum journal nötig sein. Sehe ich das richtig? Sind die Parameter von dd so ok? Hinterher müsste ich nur die Partition vergrößern.

So, noch mal ein update von mir.
Ich habe also mit dd die 5TB-Platte auf die 8TB-Platte kopiert. Dauer: 9 Stunden 16 Minuten, Transferrate beginnend mit 176 MB/s kontinuierlich abnehmend auf 150 MB/s. Laut Seagate kann die Platte maximal 190 MB/s, das passt also.
Auf der neuen Platte habe ich anschließend mit gparted eine 5 TB große primäre Partition gesehen, das hatte ich ja auch erwartet. Ich habe sie dann auf maximale Größe vergrößert.
Die alte Platte habe ich dann entfernt, sie hat ja die gleiche UUID wie die neue und vorsichtshalber mal rebootet. Allerdings habe ich nicht erwartet, dass die neue Platte sich nicht mounten lässt. Ein fsck von gparted aus brachte auch nichts. Vielleicht ist die Partitionstabelle kaputt. In gparted heißt die Partition sdd1, also habe ich

1

sudo gpart /dev/sdd1

gestartet. Das läuft jetzt schon seit über 20 Stunden und ist immer noch nicht fertig. Macht gpart noch was anderes als meinen Stromzähler zu beschäftigen?
Um das rauszukriegen habe ich mal mit einem anderen Rechner eine ausrangierte 40 GB Platte mit gpart malträtiert.
Nach zwei Stunden habe ich das abgebrochen. Wenn 40 GB in zwei Stunden noch nicht fertig sind, wie lange dauern dann 8000 GB? Wochen will ich darauf nicht warten, in der Zeit kann ich auch jede Datei einzeln kopieren.

Hat noch jemand einen Tipp?

Du wirst schlecht eine Partitionstabelle finden... auf einer Partition. Also wenn dann suchst du das ganze Laufwerk, nicht eine Partition davon.

Ein mögliches Problem mit dd ist, wenn die Laufwerke unterschiedliche logische Sektorgrößen haben. Eine Partitionstabelle für 512 Byte Sektoren sieht anders aus als eine für 4096 Byte Sektoren. Da muss man dann die Partitionstabelle neu schreiben...

Aber dann hättest du auch nicht die Partitionstabelle vergrößern können... da wäre dann einfach keine Partition da gewesen (obwohl mit dd kopiert). Ein losetup --sector-size kann einem dann aus der Patsche helfen und die Konvertierung ermöglichen...

Wenn dein /dev/alt /dev/neu eh die Partition war und nicht die ganze Platte, dann betrifft dich das Problem nicht, da hast du ja auf der neuen Platte vorher die Partitionen angelegt.

Im Zweifel ist ddrescue das bessere Werkzeug um Festplatten zu kopieren, dd kann eben auch abbrechen bzw. Daten ganz falsch kopieren (mit der noerror sync Option bekommt man Datensalat)

Bzw. wenn man keine Lesefehler erwartet auch einfach nur cp

Ich habe mit

1

sudo dd if=/dev/sdb of=/dev/sdc status=progress bs=1M

Sektor für Sektor der alten auf die neue Platte übertragen wollen, inklusive Partitionstabelle. Ich habe allerdings vor dem Vergrößern der Partition nicht überprüft, ob sie sich einhängen lässt, vielleicht ist ja beim Vergrößern irgendwas schief gelaufen.
Eigentlich erwarte ich keine Lesefehler von der alten Platte, also sollte ein einfaches 'cp' ausreichend sein. Macht cp denn was grundsätzlich anderes, als wenn ich in Caja alles von einer Platte auf die andere ziehe. Das hatte ich ja abgebrochen, weil es so furchtbar langsam war.

Wenn ich ddrescue verwende, sollte ich die ganze Platte klonen

1

ddrescue -n -v /dev/sda /dev/sdb /home/users/boss/Desktop/log0.log

oder nur die einzige auf der alten Platte befindliche Partition?

1

ddrescue -n -v /dev/sda1 /dev/sdb1 /home/users/boss/Desktop/log0.log

Dazu muss ich natürlich vorher sdb1 anlegen.
Was ist mit dem Parameter '-f ', muss ich den mit angeben?

Sollte ich die UUID der neuen Platte ändern, sie hat ja jetzt die gleiche wie die alte Platte? Ich könnte mir vorstellen, dass es Schwierigkeiten geben könnte, wenn ich beide Platten gleichzeitig anschließe.

Ja, ich weiß, Fragen über Fragen, ich hätte nicht geglaubt, dass es so mühsam ist, Dateien von einer Platte auf die andere zu kriegen. Irgendwann will ich aber damit mal fertig werden.

Vielen Dank für eure Geduld!

Wendelinchen schrieb:

Ich habe mit

1	sudo dd if=/dev/sdb of=/dev/sdc status=progress bs=1M

Sektor für Sektor der alten auf die neue Platte übertragen wollen, inklusive Partitionstabelle.

An dem Befehl ist an sich nichts falsch. Wie gesagt, sdb sdc müssen die gleiche Sektorgröße (logisch) haben. Das sollte dir von fdisk, parted angezeigt werden oder läßt sich mit blockdev abfragen. Ansonsten sollte das einfach gehen.

Ich habe allerdings vor dem Vergrößern der Partition nicht überprüft, ob sie sich einhängen lässt, vielleicht ist ja beim Vergrößern irgendwas schief gelaufen

Wie hast du denn vergrößert? Wichtig ist daß der Startsektor sich nicht ändert. Bei parted bietet sich dazu der resizepart Befehl an.

Eigentlich erwarte ich keine Lesefehler von der alten Platte, also sollte ein einfaches 'cp' ausreichend sein. Macht cp denn was grundsätzlich anderes, als wenn ich in Caja alles von einer Platte auf die andere ziehe. Das hatte ich ja abgebrochen, weil es so furchtbar langsam war.

Caja kenne ich nicht. Mit cp meinte ich cp /dev/alt /dev/neu. Also cp kann wie dd auch, ganze Blockgeräte kopieren, hat aber weniger Fehlerpotential als dd.

Dateien altmodisch kopieren geht natürlich auch.

Dazu muss ich natürlich vorher sdb1 anlegen.
Was ist mit dem Parameter '-f ', muss ich den mit angeben?

ddrescue schreibt default lieber auf ein Image-File als direkt auf ein Device. Daher das -f

Wie bei dd ist sehr darauf zu achten, daß man nicht die falsche Platte erwischt, sonst Daten futsch.

Die UUID kann man (bei ext4) mit tune2fs ändern. Die PARTUUID (bei gpt) mit gdisk irgendwo im Expertenmenü...

Kurze Antwort, ich muss gleich weg.

Die Sektorgröße ist bei beiden Platten 4096 Byte, vergrößert habe ich mit GParted, dem Standardtool von Mate um Partitionen zu bearbeiten, also sie neu zu erstellen, sie zu verkleinern/vergrößern, UUIDs zu ändern... und Caja ist der Standarddateimanager von Mate, also das, was früher mal der Explorer in Windows war.

Nachtrag

So habe ich den Kopiervorgang noch mal gestartet:

1

ddrescue -n -v -f /dev/sdb1 /dev/sdc1 /home/boss/Desktop/log0.log

Das hat wieder 9 Stunden 50 Minuten gedauert, ist aber fehlerfrei durchgelaufen. Anschließend habe ich den Rechner runtergefahren, die beiden Platten der gleichen UUID wegen entfernt und den Rechner neu gestartet.
Als ich die 8 TB-Platte wieder angeschlossen habe, wurde sie auch gleich eingebunden und geöffnet, alles ok.
Mit gparted wollte ich die Partition maximieren und habe diesmal nicht einfach nur mit der Maus den rechten Rand der Partition nach außen verschoben wie beim ersten Kopierversuch mit dd, sondern mir erstmal "Partition/Eigenschaften" angesehen. Hier kam dann ein Warnsymbol mit dem Hinweis, dass noch unbenutzter Speicherplatz in der Partition frei sei (oder so ähnlich), und dass man die Partition überprüfen sollte. Das dauerte dann nur eine Minute und anschließend hatte die Partition auch ihre volle Größe.
Dieses "Überprüfen" habe ich beim ersten Mal nicht gemacht; ich hatte mir nicht die Partitionseigenschaften angesehen. Ob das Warnsymbol nicht angezeigt wurde, oder ich es ignoriert habe, weiß ich nicht mehr. Jedenfalls wird das wohl mein Fehler gewesen sein.

Vielen Dank an alle, besonders an frostschutz, ohne Deine Hilfe würde ich jetzt hier sitzen und Datei für Datei einzeln kopieren. Bis Sylvester sollte ich dann damit auch fertig sein.