Kopieren auf USB-Platte geht schneckenlangsam, Rechner wird unbenutzbar
Hallo, ich habe ein Problem mit einer neuen USB3-Festplatte. Ich kopiere eine größere Datenmenge von ca. 2Gb auf die Platte (10k jpeg-Dateien), dafür wird der Midnight Commander verwendet, das gesamte Verzeichnis wird kopiert. Bis etwa 1/3 des Gesamtfortschrittes geht der Kopiervorgang relativ schnell, ca. 17mb/s, dann bricht die Geschwindigkeit immer weiter ein bis man mein Fortschrittsbalken für die Einzeldatei die Übertragungsrate angezeigt bekommt: *50kb/s*. Siehe "Kopierfenster" im Anhang. Irgendwann bei ca. 1/2 des Gesamtfortschrittes ist der Rechner so ausgelastet, das sich der Mauszeiger nicht mehr bewegen läßt und auch und auch alles andere sehr zäh wird. Während des gesamten Kopiervorganges wird ein Load von 2 erzeugt. Auch das Navigieren zwischen den Verzeichnissen der USB-Platte geht teilweise sehr träge (Verzeichnis wechseln > 10sek). Auch habe ich eine sehr lange Nachlaufzeit bei der Platte beobachtet. Obwohl der Kopiervorgang am Rechner anscheinend abgeschlossen ist, blinkt die Festplatte noch fast eine halbe Stunde weiter vor sich hin. Auch der Load ist noch bei 1. Ein Aushängen der Platte ist nicht möglich (Meldung "wird ausgehängt" im Gerätemanager) Ich habe schon verschiedene Ports am Rechner Probiert (auch USB 2) und ein anderes Kabel. An dem Kopiervorgang ist keine SSD beteiligt, falls das von Belang sein sollte. Was kann das sein ? Platte defekt, sollte ich die zurückschicken? Neu formattieren mit einem Linux-Dateisystem, wenn ja, welches ? System ist Suse Leap 42.3 mit allen aktuellen Uppedates. Festplatte ist diese: https://www.voelkner.de/products/812748/Seagate-Expansion-Portable-Externe-F... Jürgen
Am 16.11.2018 um 23:16 schrieb Jürgen Hochwald:
Hallo, ich habe ein Problem mit einer neuen USB3-Festplatte. Ich kopiere eine größere Datenmenge von ca. 2Gb auf die Platte (10k jpeg-Dateien), dafür wird der Midnight Commander verwendet, das gesamte Verzeichnis wird kopiert. Bis etwa 1/3 des Gesamtfortschrittes geht der Kopiervorgang relativ schnell, ca. 17mb/s, dann bricht die Geschwindigkeit immer weiter ein bis man mein Fortschrittsbalken für die Einzeldatei die Übertragungsrate angezeigt bekommt: *50kb/s*. Siehe "Kopierfenster" im Anhang. Irgendwann bei ca. 1/2 des Gesamtfortschrittes ist der Rechner so ausgelastet, das sich der Mauszeiger nicht mehr bewegen läßt und auch und auch alles andere sehr zäh wird. Während des gesamten Kopiervorganges wird ein Load von 2 erzeugt. Auch das Navigieren zwischen den Verzeichnissen der USB-Platte geht teilweise sehr träge (Verzeichnis wechseln > 10sek). Auch habe ich eine sehr lange Nachlaufzeit bei der Platte beobachtet. Obwohl der Kopiervorgang am Rechner anscheinend abgeschlossen ist, blinkt die Festplatte noch fast eine halbe Stunde weiter vor sich hin. Auch der Load ist noch bei 1. Ein Aushängen der Platte ist nicht möglich (Meldung "wird ausgehängt" im Gerätemanager) Das liegt daran, dass noch massenhaft Daten im Cache auf die Platte geschrieben werden müssen
Ich habe schon verschiedene Ports am Rechner Probiert (auch USB 2) und ein anderes Kabel. An dem Kopiervorgang ist keine SSD beteiligt, falls das von Belang sein sollte.
Ich würde mal testen, wie schnell das Lesen geht Erstmal mit dd, also in deinem Fall dd if=/dev/sdc1 of=/dev/null bs=1M count=8192 status=progress Dann eine fette Datei drauf anlegen, auch mit dd dd if=/dev/zero of=/<mountpoint>/8g bs=1M count=8192 status=progress Ich meine gelesen haben, dass externe Platten in der Geschwindigkeit dramatisch einbrechen können, wenn viele kleine Dateien drauf kopiert werden (das war irgendwann ein Artikel in der c't, allerdings ging es da um externe USB SSD Disks) Da ich aber keine externen USB Platten aktiv in Verwendung habe (war persönlich noch nie ein Fan davon), kann ich da nicht gerade auf einen großen Erfahrungsschatz zurückgreifen
Was kann das sein ? Platte defekt, sollte ich die zurückschicken? Neu formattieren mit einem Linux-Dateisystem, wenn ja, welches ?
NTFS über FUSE Treiber ist bestimmt nicht besonders schnell, würde es mal mit einem ext4 versuchen. Allerdings nur, wenn obige raw-Tests vernünftige Geschwindigkeit attestieren Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, folgende Werte hat der Test ergeben: dd if=/dev/sdc1 of=/dev/null bs=1M count=8192 status=progress 8554283008 bytes (8.6 GB, 8.0 GiB) copied, 73.0021 s, 117 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 73.3103 s, 117 MB/s dd if=/dev/zero of=/run/media/cfjh/TOSHIBA\ EXT/8g bs=1M count=8192 status=progress 8582594560 bytes (8.6 GB, 8.0 GiB) copied, 113.023 s, 75.9 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 113.124 s, 75.9 MB/s Jürgen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Jürgen ggf. hatte ich das Problem auch einmal wenn USB Speicher (oder USB Festplatte) mit im Spiel ist. https://lists.opensuse.org/opensuse-de/2015-01/msg00153.html Damals hatte ich keine Lösung gefunden, und heute neuer Rechner, anderer Kernel immer noch zu sehen. Kann jetzt keine Lösung bieten, scheint aber ein sehr alter Kernel Bug zu sein, der noch immer nicht für alle Konstellationen richtig gefixt wurde (siehe ab Comment 650) https://bugzilla.kernel.org/show_bug.cgi?id=12309 Sorry dass ich nicht mehr helfen kann, ggf. findest Du etwsa sin den Kommentaren was hilft Alexander Jürgen Hochwald wrote on 17.11.2018 00:28:
Hallo, folgende Werte hat der Test ergeben:
dd if=/dev/sdc1 of=/dev/null bs=1M count=8192 status=progress 8554283008 bytes (8.6 GB, 8.0 GiB) copied, 73.0021 s, 117 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 73.3103 s, 117 MB/s
dd if=/dev/zero of=/run/media/cfjh/TOSHIBA\ EXT/8g bs=1M count=8192 status=progress 8582594560 bytes (8.6 GB, 8.0 GiB) copied, 113.023 s, 75.9 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 113.124 s, 75.9 MB/s
Jürgen
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 17.11.2018 um 00:28 schrieb Jürgen Hochwald:
Hallo, folgende Werte hat der Test ergeben:
dd if=/dev/sdc1 of=/dev/null bs=1M count=8192 status=progress 8554283008 bytes (8.6 GB, 8.0 GiB) copied, 73.0021 s, 117 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 73.3103 s, 117 MB/s
dd if=/dev/zero of=/run/media/cfjh/TOSHIBA\ EXT/8g bs=1M count=8192 status=progress 8582594560 bytes (8.6 GB, 8.0 GiB) copied, 113.023 s, 75.9 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 113.124 s, 75.9 MB/s
Das sieht doch recht ordentlich aus, nur bin ich etwas verwirrt beim Schreibtest, ist der Pfad richtig? Lt. log in deinem Orginalpost wird die Platte nach Nov 16 22:40:57 bastau udisksd[1674]: Mounted /dev/sdc1 at /run/media/cfjh/Seagate Expansion Drive on behalf of uid 1000 gemounted Da isses eine Seagate Platte, und nu ein Toshiba? Da kann doch was nicht stimmen. Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, um zu testen ob das Problem evtl. am Rechner selbst liegt, hatte ich noch eine 2. Platte (Toschiba) getestet. Da hab' ich den Test auf der falschen Platte gemacht ... Hier die Werte für beide Platten: toschiba lesen dd if=/dev/sdc1 of=/dev/null bs=1M count=8192 status=progress 8558477312 bytes (8.6 GB, 8.0 GiB) copied, 73.0008 s, 117 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 73.5836 s, 117 MB/s toschiba schreiben dd if=/dev/zero of=/run/media/cfjh/TOSHIBA\ EXT/8g bs=1M count=8192 status=progress 8566865920 bytes (8.6 GB, 8.0 GiB) copied, 114.015 s, 75.1 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 114.311 s, 75.1 MB/s seagate lesen dd if=/dev/sdc1 of=/dev/null bs=1M count=8192 status=progress 8525971456 bytes (8.5 GB, 7.9 GiB) copied, 65.0076 s, 131 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 65.4732 s, 131 MB/s seagate schreiben
dd if=/dev/zero of=/run/media/cfjh/Seagate\ Expansion\ Drive/8g bs=1M count=8192 status=progress 8500805632 bytes (8.5 GB, 7.9 GiB) copied, 90.0011 s, 94.5 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 90.9121 s, 94.5 MB/s
Bei beiden Platten ist die Schreibaktivität auf der Platte selbst (Blinken) auch ein paar Sekunden nach dem Ende des dd-Befehles vorbei. Dann habe wie gestern noch nochmal einen Test mit Dateikopieren gemacht. Der Kopiervorgang auf die Platte selbst ging noch durchgängig relativ schnell (ca. 18Mb/s, kein Vergleich zu gestern), aber nach Ende war die Platte noch für ca. 10min aktiv. Während dieser Zeit war sie faktisch nicht ansprechbar. Auch das Zurückkopieren der auf der USB-Platte gespeicherten Daten geht in Zeitlupe (ca. 1Mb/s). Kann das am Dateisystem liegen, sollte ich es riskieren, die mit xfs (war wäre zu empfehlen) zu formattieren? Jürgen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 17.11.2018 um 13:43 schrieb Jürgen Hochwald:
seagate lesen dd if=/dev/sdc1 of=/dev/null bs=1M count=8192 status=progress 8525971456 bytes (8.5 GB, 7.9 GiB) copied, 65.0076 s, 131 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 65.4732 s, 131 MB/s
seagate schreiben
dd if=/dev/zero of=/run/media/cfjh/Seagate\ Expansion\ Drive/8g bs=1M count=8192 status=progress 8500805632 bytes (8.5 GB, 7.9 GiB) copied, 90.0011 s, 94.5 MB/s 8192+0 Datensätze ein 8192+0 Datensätze aus 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 90.9121 s, 94.5 MB/s
Bei beiden Platten ist die Schreibaktivität auf der Platte selbst (Blinken) auch ein paar Sekunden nach dem Ende des dd-Befehles vorbei.
Dann habe wie gestern noch nochmal einen Test mit Dateikopieren gemacht. Der Kopiervorgang auf die Platte selbst ging noch durchgängig relativ schnell (ca. 18Mb/s, kein Vergleich zu gestern), aber nach Ende war die Platte noch für ca. 10min aktiv. Während dieser Zeit war sie faktisch nicht ansprechbar. Auch das Zurückkopieren der auf der USB-Platte gespeicherten Daten geht in Zeitlupe (ca. 1Mb/s). Reichlich seltsam
Kann das am Dateisystem liegen, sollte ich es riskieren, die mit xfs (war wäre zu empfehlen) zu formattieren? Also ob nun xfs oder ext4 oder btrfs, scheint mir im Grunde egal zu sein, solange es nicht das Fuse/NTFS ist. Fakt ist ja wohl, dass die Platte so wie sie ist für deine Zwecke völlig unbrauchbar ist. Bleibt die ja wohl nichts anderes übrig als sie neu zu
Aha, soweit so gut. Also lässt sich mal sagen, dass die Platte in Ordnung zu sein scheint. formatieren. Was soll da schon groß passieren? - Nichts! Kann nur besser werden Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Jürgen, [START Vorbemerkung] Nein, ich möchte hier kein Seagate-Bashing betreiben und auch keinen flameware lostreten. Mit diesem Beitrag möchte ich einen Erklärungsversuch unternehmen. Dazu hole ich mal etwas aus... [STOP Vorbemerkung] Nach dem hier beschriebenen Verhalten, scheint Deine Festplatte Seagate STEA2000400 die Daten in SMR [1] aufzuzeichnen. Leider fand ich auf der Internetseite von Seagate hierzu keine Angaben. [START Exkurs] Bei den 3,5 Zoll Festplatten der Barracuda-Serie schreibt Seagate in den technischen Daten [2] auf Seite 2 und 3: 55 TB Workload im Jahr. Das entspricht rund 154 GB/Tag bei 365 Tagen Betrieb im Jahr. Dies deutet für mich auf SMR hin. Wenn ich diese Information von den 3,5 Zoll Festplatten analog auf Dein 2,5 zölliges Gerät übertrage, scheint Deine Festplatte die Daten mit SMR aufzuzeichnen. Dabei handelt es sich natürlich nur um meine Vermutung und nicht um einen absolut wasserdichten Beweis. [STOP Exkurs] Konzeptionsbedingt kommt es bei SMR zu sehr vielen *Schreibzugriffen* (Einzelheiten siehe [1]). Wenn Du nun zusätzlich zu den rund 10.000 zu schreibenden Dateien (nebst 10.000 neuen Einträgen im Inhalts- verzeichnis des Dateisystems) noch die durch SMR bedingten vielen Schreibzugriffe hinzuzählst, kannst Du Dir die interne Schreibbelastung für die Festplatten ungefähr vorstellen. Damit ist es nicht verwunderlich, dass mit fortschreitendem Schreiben die Schreibraten Deiner externen Festplatte immer kleiner werden. Die lange "Nachlaufzeit" bis die Festplatte ausgehängt werden kann, ist schlicht der Tatsache geschuldet, dass die Festplatte ihren internen Cache leert. Die zuletzt in den "Schnellschreibbereich" geschriebenen Daten werden in den "normalen" Bereich der Festplatte verschoben, wo sie dann liegen. Was könnte nun *für Deinen Anwendungsfall* eine brauchbare Lösung sein? Ich weiß es nicht. (Die Daten nur in kleinen Portionen, mit wenigen verschiedenen Dateien schreiben, ist sicher kein gangbarer Weg für Dich.) ...Themawechsel... In den SMART-Daten [3] der Festplatte hast Du sicher bereits nach Auffälligkeiten gesehen. Falls nicht, können die Gesundheitsdaten der Festplatte durch den Befehl sudo smartctl -a -H /dev/sdc ausgelesen werden. Tschüß Carsten [1] https://de.wikipedia.org/wiki/Shingled_Magnetic_Recording [2] https://www.seagate.com/www-content/datasheets/pdfs/3-5-barracudaDS1900-11-1... [3] https://de.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Techno... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 18.11.2018 um 08:16 schrieb Carsten Grebehem:
Hallo Jürgen,
[START Vorbemerkung] Nein, ich möchte hier kein Seagate-Bashing betreiben und auch keinen flameware lostreten.
Mit diesem Beitrag möchte ich einen Erklärungsversuch unternehmen. Dazu hole ich mal etwas aus... [STOP Vorbemerkung]
Nach dem hier beschriebenen Verhalten, scheint Deine Festplatte Seagate STEA2000400 die Daten in SMR [1] aufzuzeichnen. Leider fand ich auf der Internetseite von Seagate hierzu keine Angaben.
Das is absoluter, totaler, völlig blöder Schwachsinn den Du hier verbreitest. Weiter s.u.
[START Exkurs] Bei den 3,5 Zoll Festplatten der Barracuda-Serie schreibt Seagate in den technischen Daten [2] auf Seite 2 und 3:
55 TB Workload im Jahr. Das entspricht rund 154 GB/Tag bei 365 Tagen Betrieb im Jahr.
Dies deutet für mich auf SMR hin. Wenn ich diese Information von den 3,5 Zoll Festplatten analog auf Dein 2,5 zölliges Gerät übertrage, scheint Deine Festplatte die Daten mit SMR aufzuzeichnen. Dabei handelt es sich natürlich nur um meine Vermutung und nicht um einen absolut wasserdichten Beweis. [STOP Exkurs]
Hättest Du mal auf den Link geklickt, hättest Du vielleicht erkannt, dass es sich um eine 2.5" Platte handelt und *nicht* um eine 3.5", bei der SMR *manchmal* zum Einsatz kommt Weiter s.u.
Konzeptionsbedingt kommt es bei SMR zu sehr vielen *Schreibzugriffen* (Einzelheiten siehe [1]). Wenn Du nun zusätzlich zu den rund 10.000 zu schreibenden Dateien (nebst 10.000 neuen Einträgen im Inhalts- verzeichnis des Dateisystems) noch die durch SMR bedingten vielen Schreibzugriffe hinzuzählst, kannst Du Dir die interne Schreibbelastung für die Festplatten ungefähr vorstellen.
Wenn Du schon hier den Oberschlauen herauskehrst, solltest Du aber auch erwähnen, dass dieses Verhalten *erst dann* zum Tragen kommt, *nachdem* keine unbeschriebenen Tracks mehr vorhanden sind, sprich, wenn die Platte nahezu einmal komplett beschrieben worden ist. Da es sich aber um eine *neue* Platte handelt, kann das ja wohl nicht sein, zumal es sich um zu schreibende 10GB Daten handelt. Da hätte Jürgen ja schon 200x diese Daten auf die Platte schreiben müssen, was bei der derzeitigen Geschwindigkeit ja wohl Monate in Anspruch nehmen würde.
Damit ist es nicht verwunderlich, dass mit fortschreitendem Schreiben die Schreibraten Deiner externen Festplatte immer kleiner werden. Die lange "Nachlaufzeit" bis die Festplatte ausgehängt werden kann, ist schlicht der Tatsache geschuldet, dass die Festplatte ihren internen Cache leert. Die zuletzt in den "Schnellschreibbereich" geschriebenen Daten werden in den "normalen" Bereich der Festplatte verschoben, wo sie dann liegen.
Geht's noch? Die Platte hat einen internen Cache zwischen 32 und 128MB (geschätzt), mehr nicht. Das dauert maximal 2 Sekunden, um diese Daten auf die Platte zu schreiben. Das, was da so lange dauert, ist das Leeren des Caches aus dem *Arbeitsspeicher*, und der kann ja je nach System schon etliche GBytes betragen. Und *das* dauert dann halt, besonders dann wenn irgendjemand mit dem Fuß auf der Bremse steht.
Was könnte nun *für Deinen Anwendungsfall* eine brauchbare Lösung sein? Ich weiß es nicht. (Die Daten nur in kleinen Portionen, mit wenigen verschiedenen Dateien schreiben, ist sicher kein gangbarer Weg für Dich.)
Wirklich sehr hilfreiche Aussage ... Meinem Gefühl nach gibt es da zwei Gründe: 1) Das Fuse/NTFS ist für diesen Fall völlig ungeeignet 2) Irgendwie wird die Platte im 'sync' Modus gemountet, wenngleich in dem Log nichts darauf hindeutet. Aber vielleicht läuft Fuse/NTFS ja immer im sync Modus, das kann ich mangels Erfahrung nicht sagen. Vielleicht würde die Mount Option 'async' etwas bringen. Ich selbst hatte mal eine externe Platte versehentlich mit 'sync' gemountet und mich dann gewundert, warum das Schreiben darauf so dermaßen langsam war. Aber es wird bestimmt zuerst das Beste sein, das NTFS los zu werden Manfred ps Noch mal zum SMR. Ich selbst habe eine 8TB Platte von Seagate mit SMR seit fast 2 Jahren im Einsatz, und im normalen täglichen Betrieb merke ich davon *rein gar nichts*. Unter anderem rsynce ich da einmal wöchentlich die komplette Systemplatte meines Server drauf (aktuell ca. 1TB an Daten, die natürlich nicht immer komplett geschrieben werden), und da sind massenhaft kleine Dateien drauf (Kernel Sourcen, ccache Daten etc pp) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Sun, 18 Nov 2018, Manfred Kreisl schrieb:
Am 18.11.2018 um 08:16 schrieb Carsten Grebehem: [..]
Nach dem hier beschriebenen Verhalten, scheint Deine Festplatte Seagate STEA2000400 die Daten in SMR [1] aufzuzeichnen. Leider fand ich auf der Internetseite von Seagate hierzu keine Angaben.
Das is absoluter, totaler, völlig blöder Schwachsinn den Du hier verbreitest.
Ach? Findest du eine andere 2.5"/2TB Seagate-Platte als die ST2000LM015? <https://www.seagate.com/www-content/product-content/seagate-laptop-fam/barracuda_25/en-us/docs/100807728g.pdf> Seite 7. -dnh -- People are going to scream bloody murder about that. -- Seen on linux-kernel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 18.11.2018 um 17:16 schrieb David Haller:
Hallo,
Am Sun, 18 Nov 2018, Manfred Kreisl schrieb:
Am 18.11.2018 um 08:16 schrieb Carsten Grebehem: [..]
Nach dem hier beschriebenen Verhalten, scheint Deine Festplatte Seagate STEA2000400 die Daten in SMR [1] aufzuzeichnen. Leider fand ich auf der Internetseite von Seagate hierzu keine Angaben.
Das is absoluter, totaler, völlig blöder Schwachsinn den Du hier verbreitest.
Ach? Findest du eine andere 2.5"/2TB Seagate-Platte als die ST2000LM015? <https://www.seagate.com/www-content/product-content/seagate-laptop-fam/barracuda_25/en-us/docs/100807728g.pdf> Seite 7.
Sorry, der Punkt geht an dich. Das ändert per se aber nichts an der Tatsache, das SMR in diesem Falle garantiert nicht der Übeltäter ist Auf Seite 7 finde ich übrigens nix, sondern vielmehr auf Seite 6 Und nun wissen wir auch, dass die Platte 128MB Cache hat :) Und wenn wir dann mal von einer gemittelten Geschwindigkeit von 70MB/s ausgehen, dann ist der Cache in weniger als 2s auf der Platte Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 18.11.2018 um 18:44 schrieb Manfred Kreisl:
Am 18.11.2018 um 17:16 schrieb David Haller:
Hallo,
Am Sun, 18 Nov 2018, Manfred Kreisl schrieb:
Am 18.11.2018 um 08:16 schrieb Carsten Grebehem: [..]
Nach dem hier beschriebenen Verhalten, scheint Deine Festplatte Seagate STEA2000400 die Daten in SMR [1] aufzuzeichnen. Leider fand ich auf der Internetseite von Seagate hierzu keine Angaben.
Das is absoluter, totaler, völlig blöder Schwachsinn den Du hier verbreitest.
Ach? Findest du eine andere 2.5"/2TB Seagate-Platte als die ST2000LM015? <https://www.seagate.com/www-content/product-content/seagate-laptop-fam/barracuda_25/en-us/docs/100807728g.pdf>
Seite 7.
Sorry, der Punkt geht an dich. Das ändert per se aber nichts an der Tatsache, das SMR in diesem Falle garantiert nicht der Übeltäter ist Auf Seite 7 finde ich übrigens nix, sondern vielmehr auf Seite 6
Und nun wissen wir auch, dass die Platte 128MB Cache hat :)
Und wenn wir dann mal von einer gemittelten Geschwindigkeit von 70MB/s ausgehen, dann ist der Cache in weniger als 2s auf der Platte
Manfred
Hi, das Problem ist möglicherweise ein mc-Problem. Versuch mal ein schlichtes cp oder auch rsync. Ich habe mc den ganzen Tag am Laufen, aber wenn ich zu Hause relativ kleine (1MB) Bilddateien damit hin-und herkopiere, finde ich auch, dass er manchmal nach hinten zu ziemlich langsam wird. Ich glaube, er übergeht den Nutzen der Caches, indem er zwischen den einzelnen Kopiervorgängen immer wieder das Zielverzeichnis neu einliest. Es wird z.B. auch ganz schnell langsam, wenn er Dateien aus einer zip oder so holen soll, die ersten paar gehen da auch ganz schnell... Die Stärken von mc liegen nicht so bei Dingen, die der gemeine Linuxer mit rsync oder so machen würde. Brotschneiden ist mit dem Schweizer Taschenmesser bei einem dicken Brot auch nicht so toll, aber dafür kann man damit auch Kreuzschlitzschrauben reindrehen, da ist ein Brotmesser eher nicht so toll geeignet... Ist aber nur eine Vermutung, und NTFS würde ich auch nur nehmen, wenn ich WinDoof-Kompatibilität brauche. cu jth -- Joerg Thuemmler -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Habe die Platte jetzt neu formattiert (mit xfs). Testweise nochmal 16Gb Daten (10k Einzeldateien) kopiert, dauerte ca. 4 Min. bei (angezeigten) 70Mb/s. Auch ist die Platte nach Ende des Kopiervorganges am Pc auch sofort wieder "ruhig", kein ewig langes Nachlaufen wie vorher. Ntfs scheint dafür wohl total untauglich zu sein. Jürgen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (6)
-
Alexander Thuermer -
Carsten Grebehem -
David Haller -
Joerg Thuemmler -
Jürgen Hochwald -
Manfred Kreisl