Hallo, Am Wed, 12 Jul 2017, Alex Winzer schrieb:
On 7/12/2017 8:19 PM, David Haller wrote:
Am Wed, 12 Jul 2017, Christian Meseberg schrieb:
Christian Meseberg meinte am Mittwoch, den 12.07.2017 um 18:41 Uhr
die SSD muss mindestens genau so groß oder größer als die HDD sein. Sonst sehe ich keine Probleme dabei. Bei der Blockgröße solltest Du bei großen Platten schon mal was drauf geben, sonst dauert es ewig. schau mal hier: https://www.heise.de/ct/hotline/Optimale-Blockgroesse-fuer-dd-2056768.html
ein Nachtrag:
Es sollte darauf geachtet werden, dass die beiden Festplatten gleich groß sind - oder zumindest das Ziel größer. Auch die Sektorengröße (512 Bytes oder Advanced Format mit 4096 Bytes) muss bei Beiden identisch sein.
Da muss ich mal doof nachfragen: Gibt es denn Geräte/SSD, wo die Blockgröße <> 512 Bytes ist?
Jep, HDDs z.B. wobei z.Z. die meisten für "Consumer" (noch) 512B Blocks emulieren (512e). Bei Server-HDDs sind glaub schon 4k Usus. Und bei CDs/DVDs sind z.B. 2048 + Fehlerkorrektur üblich (da muß man wieder zw. Daten und Audio unterscheiden), und Tapes haben AFAIK auch gerne mal andere Blockgrößen. Und wie gesagt, auch wenn 512B Blöcke emuliert werden, wenn du die HDD/SSD dann unpassend formatierst muß diese dann einen echten Block (bisher AFAIK nur 4k bei HDDs, bei SSDs irgendwas, meist wohl 128k! *UPS* NACHTRAG: inzwischen wohl 512kB!) komplett gelesen werden, geändert, und wieder geschrieben werden. Wenn's ganz blöd läuft werden also _vieeeele_ Blöcke (oder einer mehrfach) geschrieben, um einen einzigen Block im FS zu aktualisieren/zu schreiben. Lesen, ändern, schreiben. Wenn dann noch die 4k Sektoren der Platte "verschoben" zur Logik sind, wird's ganz übel. Die Performance ist dabei noch das geringste Übel (je nach Anwendung ;) Der größte Witz ist ja dabei, daß so gut wie alle (Linux-)Dateisysteme und NTFS per default sowie FAT32 ohne "Brechstange" nativ mit 4k Blöcken hantieren (IIRC). Die dröseln dann die Änderung auf die 512B auf, schreiben die womöglich _einzeln_ (lesen, ändern, schreiben) auf die HDD/SSD, und letztlich landet nur ein 4k Block auf der Platte/SSD. "Worst Case"[tm] wäre dann wohl 8 Lese+Schreibzugriffe auf der HDD/SSD für 1 Byte in nem 4k Block des FS... Es sei denn das FS schreibt nur den einen veränderten 512B Block. Ich bin da aber nicht auf dem aktuellen Stand was sowas angeht, obiges ist theoretisch. In der WP ist das wohl ganz gut aufgedröselt, Stichwort ist "Write Amplification", was quasi den Extraaufwand beschreibt, der durch ne verschobene Partitionierung, aber auch durch nur teilweise Änderungen eines "Erase Blocks" (512k) einer SSD entsteht. Bzgl. einer verschobenen 4k HDD gilt das aber genauso, nur eben bezogen auf 4k Blöcke. https://en.wikipedia.org/wiki/Write_amplification https://en.wikipedia.org/wiki/Partition_alignment https://de.wikipedia.org/wiki/Solid-State-Drive#Ausrichtung und insbesondere https://de.wikipedia.org/wiki/Solid-State-Drive#Methoden_der_Nutzungsverteil... Wie geschrieben, das gilt sinngemäß auch für die logischen 512B in 4kB Blökcken einer 4k/512e HDDs. Nur macht einer HDD normal ein Schreibvorgang eher nix aus im Vergleich zu ner SSD, bis da so Wutzl magnetisierbarer Partikel "ausgeleiert" ist, brauchts Größenordnungen mehr an Schreibvorgängen. Manche "Wutzl" sind aber schon "aus der Fabrik" defekt, wenn genug davon hintereinander vorkommen nennt sich das dann defekte Sektoren (es gibt ein paar extra Wutzl für die Fehlerkorrektur, die reicht aber halt nur für ein paar defekte Wutzl) ;) Die Wutzln werden aber eben immer kleiner und enger nebeneinander hingeschrieben, früher flach, seit, oh, vielen Jahren "senkrecht" ("perpendicular dingens recording"), und die "Spuren" dieser inzwischen sogar so eng nebeneinander, daß sich die Spuren des Schreibkopfes überlappen ("shingled dingens bla"), siehe die "Archive" Seagates. Wobei WD jetzt auch sowas baut... ["Wutzl" ~ "magnetische Domäne" aka "magnetisierbare Ansammlung von Atomen die noch als so oder andersrum magnetisiert unterschieden werden können"] Kurzum: Richte die Partitionen auf 1MB / 2048 Sektoren aus! Sowohl auf HDDs als auch SSDs.
Vor allem sollte man bei der SSD aber darauf achten, daß die Partitionen passend ausgerichtet sind, ähnlich wie bei 4k Platten, nur sind's bei SSDs gerne noch etwas mehr (128k z.B.). Kurzum: Partitionen an 1MiBi Grenzen ausrichten, was allerdings inzwischen default bei den meisten Tools ist, wenn man die Partitionen neu anlegt, aber bei so ner 1:1 Kopie ...
Was kann denn schlimmsten Fall passieren, wenn es nicht passt? Das System fährt nicht mehr hoch. Hardwarefehler dürften doch dadurch nicht entstehen, oder?
Äh, letztlich schon. Siehe oben, deine SSD könnte "vorzeitig" an defekten Speicherstellen leiden aka verrecken, wenn auch nicht spontan elektronisch, was sonst gern Todesursache Nr. 1 der SSDs im c't Langzeittest war[1], IIRC haben sich die meisten SSDs von "jetzt auf gleich" ohne Vorwarnung final eben nicht "verabschiedet"...
Ggfs. mal die Ausgabe von:
# gdisk -l /dev/sdX
herzeigen.
Und dann partitionsweise die _DATEISYSTEME_ klonen anstatt die ganze Platte. [...]
Wie mache ich das?
Klone /dev/sd${QUELLE}1 auf /dev/sd${ZIEL}1, Klone /dev/sd${QUELLE}2 auf /dev/sd${ZIEL}2, ... anstatt /dev/sd${QUELLE} auf /dev/sd${ZIEL} zu klonen. Oder evtl. besser: partitioniere das Ziel nach Gusto, formatiere diese Partitionen dann mit dem gewünschten Dateisystem und klone dann die Daten. Zwecks booten mußt du eh rumschrauben. Und so hast du zumindest keine zwei FS mit gleicher UUID im System. Bzgl. Win-Spezialitäten weiß ich's aber nicht, aber IIRC hab ich mal per "tar" ein WinXP auf ne neue HDD umgezogen...
Ich frage nicht ohne Anlass. Ich hatte des System neu aufsetzen müssen nach einem missglückten Backup. Dazu hatte ich mit "dd if=/dev/sda1 of=/home/sda1.img" die Partitionen gesichert. Dann wollte ich _nur die Partition_ löschen mittels "dd if=/dev/zero of=/dev/sda1" und am Ende war der MBR weg - selbstredend ohne Backup :-(
Hurps. Das passt nicht ganz. dd if=/dev/sda1 of=/home/sda1.img # OK, aber sichert _NUR_ # Partition 1 dd if=/dev/zero of=/dev/sda1 # OK Wenn der MBR weg war, hast du wohl beim zweiten Schritt die 1 hinter dem sda1 weggelassen... Nächstesmal: sowas läßt sich mit testdisk / part<irnkwas> meistens restaurieren. Grub(2) legt IIRC auch irgendwo ein Backup des MBR ab... Da kann dann aber auch ne "uralte" Partitionierung drinstecken.
Falls man plant beide Platten gleichzeitig im selben PC zu betreiben, ist darauf zu achten, dass die UUIDs der geklonten Platte geändert werden, da es sonst zu Konflikten kommt.
Kein Platz im Laptop dafür. Da die SSD die HDD ersetzen soll, muss ich da also nicht drauf achten.
Gut. Ggfs. halt auch beim Anschluss via USB/eSATA drauf achten.
Jep, das auch. Ggfs. vor dem Klonen auf /dev/sd* umstellen und anschließend zurück zu (neu-generierten) UUIDs / LABELs.
Jetzt aber noch zu Windoof: Bei Retail-SSDs bekommst meist ein Klon-Tool für Windows mit dazu. IIRC müßte ich hier eins von Samsung haben, mangels Windows (neuer als 95 in ner VM ;) brauch ich das eh nicht, würde es dir also "verkaufen" falls ich's find ;).
Danke. Ich versuche es erstmal mit dd. Erstmal muss das Ding kommen. Offenbar hat dieser komische Tag beim Amazonas einen Nachfrageboom ausgelöst. Vorhin sollte die SSD übermorgen kommen; jetzt ist es schon mind. nächsten Dienstag. Ich melde mich und erlaube mir ggf. nochmal nachzufragen.
Ok. Sag Bescheid wenn ich graben soll ;) Win > 8 hat soviele Haken in die Hardware ... HTH, -dnh [1] der kürzlich dann mit dem "Tod" der Samsung 850 Pro zu Ende ging ;) https://heise.de/-3755009 oder in Langform: https://www.heise.de/newsticker/meldung/SSD-Langzeittest-beendet-Exitus-bei-... -- Zoe: "Sir, I think you have a problem with your brain being missing." --Episode #2, "The Train Job" -- 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