Servus beinand, folgende Situation: Ich habe hier einen PC mit einem Linux drauf (Linux archlinux 5.0.2-arch1-1-ARCH #1 SMP PREEMPT Thu Mar 14 18:47:49 UTC 2019 x86_64 GNU/Linux). Der PC ist mittelalt, die CPU taugt für den täglichen Gebrauch (AMD FX(tm)-6300 Six-Core Processor). Im PC verbaut sind eine etwas ältere SSD (Kingston SSDNow V Series 128GB). Außerdem eine recht neue, herkömmliche Festplatte als Datengrab (Seagate Barracuda Compute, ST3000DM007-1WY10G). Ich benutze regelmäßig dd um Images meiner RaspPi-Sd-Karten zu ziehen. Wenn ich ein Image auf eine SD-Karte zurückspielen möchte (also einen Schreibzugriff auf die Karte) dann dauert es sehr lange wenn ich das Image von der Datenplatte lese. dd zeigt eine Schreibgeschwindigkeit von ~2-3Mb/s (status=progress ist ein tolles Feature). Verschiebe ich das Image dagegen vorher auf die SSD kann die Karte viel schneller beschrieben werden (~ 20-30MB/s, also Faktor 10). Bei der SD-Karte handelt es sich um irgendeine von der Stange, Sandisk Ultra, die am PC in einem USB2.0-Kartenleser betrieben wird. Witzigerweise geht der Kopiervorgang des Images von SSD auf HDD auch sehr schnell. Was ich nicht verstehe: Die SD-Karte kann die Daten prinzipiell schnell schreiben, denn von der SSD-Platte klappts ja. Der Flaschenhals scheint die Datenplatte zu sein. Ich kann mir aber irgendwie nicht vorstellen dass eine, relativ neue Festplatte, die Daten langsamer hergibt als eine SD-Karte über USB sie wegschreiben kann. Beide Festplatten sind über SATA angebunden, d.h. das USB-Subsystem kann eigentlich auch nicht der Flaschenhals sein. Hat hier irgendjemand eine Idee?
Ums nochmal zusammen zu fassen: Kopiervorgang HDD => SD-Karte: sehr langsam (2-3 MB/s) Kopiervorgang SSD => SD-Karte: normal, bzw. i.O. (20-30 MB/s) Kopiervorgang HDD => SSD: geht ruckzuck. Das Image hat um die 4 Gb.
Zu der Ursache weiß ich nichts, ich habe auch schon die Beobachtung gemacht, daß die Schreibgeschwindigkeit auf SD-Karten beim Rückspielen eines Images deutlich langsamer ist als das Beschreiben mit einzelnen Dateien. Nur ist bei mir so ziemlich alles an der Konfiguration anders als bei Dir: Windows, interner Kartenleser, fast alle SD-Karten von SanDisk.
Unter Linux kann man sich das auch einfacher machen. Habe mir angewöhnt, das Sichern der Raspi-Karten auf dem lebenden Raspi, mit dem steinalten tar zu machen. Zum Sichern nutze ich das anhängende Script, auf dem RasPi. Dort werden beide Dateisysteme unter /mnt/boot und /mnt/root neu gemountet, und mit tar gesichert. Die Ausgabe von tar wird per ssh zu dem Host geschleust, von dem ich mich an den Raspi angemeldet habe, dort gezippt (wegen der besseren CPU-Leistung, dafür gehen die Daten unkomprimiert über das Netzwerk) und unter $HOME/puffer (bitte anpassen) abgelegt. Durch das neue mounten vermeidet man, das unerwünschte Pfade (/dev, /proc ...) mit im Archiv landen. In diesem Archiv gibt es jetzt zwei Hauptzweige: boot und root. Wenn man jetzt eine neue Karte machen möchte, legt man mit gparted die beiden Partitionen an (1. FAT32 mit 44MB, 2. ext4 mit dem Rest), mountet sie unter "/mnt/boot" und "/mnt/root", dann entpackt man (aus Sicht von /mnt) das gesicherte archiv. cd /mnt sudo mount /dev/sdc1 boot sudo mount /dev/sdc2 root sudo tar xf <Archivname> Jezt muss nur noch mit fdisk die Datenträgerbezeichnung gesetzt werden, da sich /etc/fstab darauf bezieht, sonst seine Dateisysteme nicht finden würde. Wenn man sich die nicht vorher am lebenden System notiert hat, findet man sie ja noch im Archiv unter root/etc/fstab. Auf diese Weise, muss die Zielkarte nicht die gleiche Größe haben, wie das Original, nur die Daten müssen drauf passen. Mit dd wird stattdessen die Zielkarte immer "bis zum Rand" vollgeschrieben, auch wenn dort eigentlich keine Daten drin stehen. Bei meinen Raspis, mit 1,3GB belegtem Dateisystem, kommen knapp 600MB als .tar.gz raus. Sind einige Schritte mehr auszuführen, dafür müssen deutlich weniger Daten bewegt werden, aber insbesondere das Sicherungsscript erspart viel Arbeit.
Hallo Kopierer schrieb: > Was ich nicht verstehe: > Die SD-Karte kann die Daten prinzipiell schnell schreiben, denn von der > SSD-Platte klappts ja. > Der Flaschenhals scheint die Datenplatte zu sein. Mit welcher Blockgröße BS wird denn kopiert? Wenn nix angegeben ist, dürfte der Defaultwert 512 Bytes sein und das ist sicherlich ungünstig. Ich würde da mal mit den Werten spielen, z.B. bs=1M. MfG
Hi Ingo, deine Antwort geht leider am Thema vorbei. Mein "Backupsystem" ist schon etwas intelligenter als nur ein handgetipptes dd. Aber das dd-Beispiel ist das Minimalbeispiel welches das (m.M.n.) Fehlverhalten produziert. @ M.M.M.: ich verwende bs=4M. Sonst keine Paramter. Mein dd-Aufruf sieht wie folgt aus:
1 | dd if=meinBackup.img of=/dev/DeviceFilederSdKarte bs=4M status?progress |
Liegt meinBackup.img auf der kleinen internen SSD dann gehts flott. Liegt meinBackup.img auf der großen internen HDD dann wirds zäh. Zu zäh, meiner Meinung nach. Der Flaschenhals ist also nicht die Schreibgeschwindigkeit der SD-Karte. Und auch die HDD kann, normalerweise, die Daten schnell genug liefern. Nur die Kombi SD-Karte/HDD macht Probleme. Beide Platten hängen am SATA. Hat noch jemand eine Idee was da los sein könnte?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.