Ali_As
Anmeldungsdatum: 22. Mai 2012
Beiträge: 4741
Wohnort: Steinbruch
|
Hallo zusammen! Mir ist hier etwas recht seltsames passiert, was ich mir nicht erklären kann. Modell: ATA CT500MX500SSD1 (scsi)
Festplatte /dev/sdb: 500GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 1049kB 87,0GB 87,0GB ext4
2 237GB 244GB 7552MB linux-swap(v1)
3 244GB 297GB 52,6GB ext4
4 297GB 500GB 203GB ext4
Modell: ASMT 2115 (scsi)
Festplatte /dev/sdc: 120GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 1049kB 87,0GB 87,0GB ext4 diag
2 87,0GB 95,4GB 8403MB linux-swap(v1) diag
3 95,4GB 120GB 24,6GB ext4
Ich hatte kürzlich also mit dd eine 120GB SSD,hier sdc, auf eine 500GB SSD, hier sdb, geklont. Hat soweit auch alles gut geklappt. Alle beteiligten OS laufen normal. Heute wollte ich eine Änderung an der neuen 500er (Part. 3 vergrößert und 4 neu angelegt) vornehmen und traue meinen Augen nicht. Da klafft zwischen den Partitionen 1 und 2 jetzt ein riesiges Loch. 😠 (Die alte SSD ist hier als sdc mit Adapter angestöpselt, vorne hängt noch eine sda mit Windows) Kann mir das jemand erklären? Dank im Voraus! L.G.
|
exoon
Anmeldungsdatum: 29. Oktober 2012
Beiträge: Zähle...
|
Kannst du beide Tabellen mal mit Sektornummern, statt mit GB anzeigen lassen?
|
Ali_As
(Themenstarter)
Anmeldungsdatum: 22. Mai 2012
Beiträge: 4741
Wohnort: Steinbruch
|
fdisk sagt: Festplatte /dev/sdb: 465,8 GiB, 500107862016 Bytes, 976773168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 8DEE0A99-C933-45C7-B6E6-52BE90A8671F
Gerät Anfang Ende Sektoren Größe Typ
/dev/sdb1 2048 169949183 169947136 81G Linux-Dateisystem
/dev/sdb2 462483456 477233151 14749696 7G Linux Swap
/dev/sdb3 477233152 579987455 102754304 49G Linux-Dateisystem
/dev/sdb4 579987456 976773119 396785664 189,2G Linux-Dateisystem
Festplatte /dev/sdc: 111,8 GiB, 120034123776 Bytes, 234441648 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 8DEE0A99-C933-45C7-B6E6-52BE90A8671F
Gerät Anfang Ende Sektoren Größe Typ
/dev/sdc1 2048 169949183 169947136 81G Linux-Dateisystem
/dev/sdc2 169949184 186361855 16412672 7,8G Linux Swap
/dev/sdc3 186361856 234439980 48078125 22,9G Linux-Dateisystem
bzw. sfdisk sagt: sudo sfdisk -d /dev/sdb
label: gpt
label-id: 8DEE0A99-C933-45C7-B6E6-52BE90A8671F
device: /dev/sdb
unit: sectors
first-lba: 34
last-lba: 976773134
/dev/sdb1 : start= 2048, size= 169947136, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=9BB4F5F7-4FF7-494A-87A1-74952542DB07
/dev/sdb2 : start= 462483456, size= 14749696, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F, uuid=1523AABC-ECCB-438F-A484-F0A2E578CD3F
/dev/sdb3 : start= 477233152, size= 102754304, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=FD448598-EB67-48E0-A608-4BF00DEC9B52
/dev/sdb4 : start= 579987456, size= 396785664, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=35CAE3AF-4CD8-4AEF-883A-E1A8D6D09A45
label: gpt
label-id: 8DEE0A99-C933-45C7-B6E6-52BE90A8671F
device: /dev/sdc
unit: sectors
first-lba: 34
last-lba: 234441614
/dev/sdc1 : start= 2048, size= 169947136, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=9BB4F5F7-4FF7-494A-87A1-74952542DB07
/dev/sdc2 : start= 169949184, size= 16412672, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=1523AABC-ECCB-438F-A484-F0A2E578CD3F
/dev/sdc3 : start= 186361856, size= 48078125, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=FD448598-EB67-48E0-A608-4BF00DEC9B52
|
exoon
Anmeldungsdatum: 29. Oktober 2012
Beiträge: 20
|
Mehr als das die physikalische Sektorengröße unterschiedlich ist, fällt mir nicht auf. Würde jetzt nicht denken, dass das eine Rolle spielt, aber man steckt da nicht drin.
|
dingsbums
Anmeldungsdatum: 13. November 2010
Beiträge: 3553
|
Ein direktes dd-Cloning zwischen 512Bytes- und 4K-Drives ist wohl nicht ganz so "easy", siehe hier oder hier. Die komische Lücke erklärt sich für mich dadurch aber auch nicht so recht. War da beim Klonen ein USB-Adapter dazwischen?
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
Es könnte auch daran liegen, dass die IDs bei den zwei ge-clonten Festplatten überall gleich sind. Was da alles passieren kann will ich gar nicht wissen, weil bei Zugriffen über die ID nicht klar ist worauf zugegriffen wird (der 1. gewinnt?). Was die Kopie mit dd betrifft, wenn die komplette Festplatte damit kopiert wird, dann wird auch die Partitionstabelle damit kopiert. D.h. unabhängig von der logischen oder physikalischen Sektorgröße müssen in der Partitionstabelle die gleichen Werte stehen (so wie die gleichen IDs übertragen werden, die man dann unbedingt ändern muss, wenn man beide weiter gleichzeitig nutzen will). Was ich nur bisher hatte, das war, wenn die logischen Sektorgrößen nicht stimmten, dass dann die Einträge in der Partitionstabelle nach der Kopie nicht passen, weil dort die Werte für eine Festplatte mit anderer logischen Sektorgröße stehen. Das bezieht sich dann aber nur auf die Partition und nicht auf das Dateisystem darauf. Das Dateisystem, wie ext4, nutzt eine eigenen unabhängige Verwaltung, weshalb nach einer Partitonsvergrößerung das Dateisystem ohne Anpassung von der neuen Größe auch nichts weiß. Wie wurde denn ge-clont? Mit welchem genauen Befehl (dd if=/dev/sdc of=dev/sdb)? Die Werte in der Partitionstabelle werden dabei nicht verändert, da die Tabelle auch nur kopiert wird.
|
exoon
Anmeldungsdatum: 29. Oktober 2012
Beiträge: 20
|
Kannst du das Problem denn reproduzieren oder war es nur eine einmalige Sache?
|
Ali_As
(Themenstarter)
Anmeldungsdatum: 22. Mai 2012
Beiträge: 4741
Wohnort: Steinbruch
|
Hallo! Dass die ID und Partitionstabelle gleich sind, war hier Sinn der Sache, da die große SSD die kleine ersetzen sollte. Dass das bei Parallelbetrieb Probleme geben könnte ist klar.
Wie wurde denn ge-clont? Mit welchem genauen Befehl (dd if=/dev/sdc of=dev/sdb)?
Yepp! der hundsordinäre Klonbefehl eben. Was mir retrospektiv noch einfiel ist, dass das erst beim 3. Anlauf geklappt hat. Beim 1. wurde bei ca. 7GB, beim 2. bei ca 14 GB abgebrochen. Das kannte ich aber schon von früherer Verwendung von dd und seh das nicht als Ursache für dieses Riesenloch. Beim 3. lief es dann durch. Ich hab das dann auch gleich mit parted überprüft, ob die Partitionen identisch groß sind, die große Lücke ist mir dabei aber entgangen. Das hab ich erst ein paar Tage später bei Gparted mit den schönen großen optischen Balken gesehn (so viel zum Thema Augen auf in der Kommandozeile!).
War da beim Klonen ein USB-Adapter dazwischen?
Ja! Dieses Teil! L.G.
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
Ali_As schrieb: Hallo! Dass die ID und Partitionstabelle gleich sind, war hier Sinn der Sache, da die große SSD die kleine ersetzen sollte. Dass das bei Parallelbetrieb Probleme geben könnte ist klar.
Wie wurde denn ge-clont? Mit welchem genauen Befehl (dd if=/dev/sdc of=dev/sdb)?
Yepp! der hundsordinäre Klonbefehl eben. Was mir retrospektiv noch einfiel ist, dass das erst beim 3. Anlauf geklappt hat. Beim 1. wurde bei ca. 7GB, beim 2. bei ca 14 GB abgebrochen. Das kannte ich aber schon von früherer Verwendung von dd und seh das nicht als Ursache für dieses Riesenloch. Beim 3. lief es dann durch. Ich hab das dann auch gleich mit parted überprüft, ob die Partitionen identisch groß sind, die große Lücke ist mir dabei aber entgangen. Das hab ich erst ein paar Tage später bei Gparted mit den schönen großen optischen Balken gesehn (so viel zum Thema Augen auf in der Kommandozeile!).
War da beim Klonen ein USB-Adapter dazwischen?
Ja! Dieses Teil! L.G.
Achtung! Diese Fehler hätten Dich misstrauisch machen müssen. Da Du den kompletten Befehl nicht angegeben hast, bei mir gehört dazu immer auch die Blocksize-Angabe (bs=..) und bei den Fehlern wäre wichtig gewesen ob die Quelle oder das Ziel als Ursache gemeldet wurde. Der angegebene SATA-USB-Umsetzer hat keine extra Stromversorgung, d.h. der muss vom USB gespeist werden und Du weißt, dass es nicht egal ist an welchem USB-Port Du so was betreibst? Da "dd" die Daten nicht selbst verändert und die Daten in der Partitionstabelle gehören da genauso dazu wie die Daten in den ersten Sektoren in denen z.B. der boot-loader für nicht UEFI steht und natürlich die Partitionsdaten selbst auch nicht, würde ich fast darauf tippen, dass Du bei der Kontrolle (natürlich) unbeabsichtigt die Partitionstabelleneinträge hast korrigieren lassen. Was Deine angegebenen Daten betrifft, da sollte Dir auffallen, dass die letzte Partition gerade noch so drauf gepasst hat. Wie hast Du denn das "dd" vorgenommen? Mit einer Life-Version und darauf geachtet, dass die nicht den vorhandenen "swap" einbindet? Wieso hast Du nicht zusätzlich die log-Einträge kontrolliert als die Fehler aufgetreten sind? Es gibt keine Erklärung, wenn Du nicht mehr Informationen lieferst auch wenn Du meinst es sei nebensächlich. Nochmal, dd ändert nicht die Inhalte der kopierten Daten und schon gar nicht so, dass der Inhalt der Partitionstabelle automatisch mit der Position von kopierten Partitionen übereinstimmt. Ausnahme, der von Dir angegebene SATA-USB-Kontroller macht selbst so was (d.h. die Daten beim Transfer verändern ...). Ich habe 2 verschiedenen SATA-USB-Adapter (für USB-2.0 und 3.0) und die machen das nicht. Das sind aber andere Modelle mit extra Stromversorgung und es können auch alte IDE-Festplatten angeschlossen werden (der weitere Unterschied ist die logische Blockgröße mit der beide arbeiten 512 Byte ⇐> 4096, was dazu führt, dass man je nach Controller an dem man die Kopie einsetzen will, die Werte der Partitionstabelle korrigieren muss, weil die eben 1:1 übertragen werden).
|
Ali_As
(Themenstarter)
Anmeldungsdatum: 22. Mai 2012
Beiträge: 4741
Wohnort: Steinbruch
|
Da Du den kompletten Befehl nicht angegeben hast,
Doch habe ich, siehe Bestätigung des letzten Zitats des Kollegen. Zufällig ist/war es sogar der identische Befehl. dd if=/dev/sdc of=dev/sdb Diesen Adapter habe ich tatsächlich erstmalig benutzt. Davor ein älteres Modell mit eigener Stromversorgung. Ich gehe aber davon aus, dass die Stromversorgung gewährleistet war. Der Rechner selbst ist ein DELL Optipex, kompakte Bauform, neuerer Bauart, also Arbeitstier! Selbstverständlich wurde das Ganze von der Live-Session aus erledigt, da ja die Systempartition betroffen ist/war.
Da "dd" die Daten nicht selbst verändert und die Daten in der Partitionstabelle gehören da genauso dazu wie die Daten in den ersten Sektoren in denen z.B. der boot-loader für nicht UEFI steht und natürlich die Partitionsdaten selbst auch nicht, würde ich fast darauf tippen, dass Du bei der Kontrolle (natürlich) unbeabsichtigt die Partitionstabelleneinträge hast korrigieren lassen.
Welche Kontrolle? Die Überprüfung, ob alles geklappt hat? Das wurde eigentlich erst aus dem laufenden System heraus erledigt.
...und darauf geachtet, dass die nicht den vorhandenen "swap" einbindet?
Das habe ich tatsächlich nicht gemacht. Habe ich noch nie gemacht, hat noch nie Probleme gemacht. Aber Danke für den Hinweis! Die Log-Dateien hab' ich nicht eingesehen, weil ich entsprechende Erfahrungen mit dd vorher schon hatte, dass es erst im 2. oder 3. Anlauf klappt. Was sich ja auch hier wieder bestätigt hat. Nur dass da bei anderen Gelegenheiten auf zig verschiedenen Rechnern noch nie so ein Krater entstanden ist.
Nochmal, dd ändert nicht die Inhalte der kopierten Daten und schon gar nicht so, dass der Inhalt der Partitionstabelle automatisch mit der Position von kopierten Partitionen übereinstimmt.
Ja denkst du, das wüsste ich nicht? Deshalb habe ich ja diesen Thread eröffnet um zu erfahren, wo der Hase im Pfeffer liegt. Vielleicht mache ich noch mal einen Test mit dem herkömmlichen Adapter. Dass dort die Fehlerquelle liegt ist wohl nicht gänzlich auszuschließen. L.G.
|
fornext
Anmeldungsdatum: 21. Januar 2008
Beiträge: 165
|
Der Parameter bs ist nicht notwendig, kann aber sinnvoll sein. Meistens geht es auch ohne wunderbar. DD ist bei mir bisher immer stabil gelaufen. Allerdings hatte ich auch schon ein paar USB-Adapter, die einfach Mist waren. Eine Kontrolle über einen HASH-Wert sollte bei wichtigen Daten eigentlich Pflicht sein - auch wenn es lange dauern kann. Man muss nur aufpassen, dass man bei der größeren Platte nur den Teil der geschrieben wurde berücksichtigt. Das Argument von alterpinguin ("...der weitere Unterschied ist die logische Blockgröße mit der beide arbeiten 512 Byte ⇐> 4096...") stimmt zwar, zählt hier aber nicht, da nicht die logische, sondern die physikalische Sektorengröße unterschiedlich ist.
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
@Ali_As: ich kann nur nochmal darauf hinweisen, dass es nicht normal ist, dass eine dd-Kopie regelmäßig Fehlermeldungen liefert und die Kopie erst nach 2-3 Fehlermeldungen "sauber" abgelaufen ist. Das ist nicht "sauber"! Da ist der Murks drin und Du bist dem nur nie nachgegangen. Ich habe so etwas definitiv noch nie gesehen und wenn ich Fehlermeldungen hatte, dann war das z.B. wg. teilweise defekter Festplatten oder Controllerfehlern. Solche Fehler lassen sich genauer in den Log-Dateien nachsehen, z.B. wenn der betreffende Daten-Bus resetet wird etc.. @fornext: richtig, die je nach Controller genutzte Blockgröße (meist entweder 512 oder 4092) hat eigentlich keinen Einfluss auf die Kopie der Daten. Jedenfalls gab es das bei mir noch nie mit solchen unterschiedlichen Kontrollern. Ich habe nur darauf hingewiesen, weil man darüber stolpert, wenn man so eine Kopie an einem anderen Kontroller betreiben will und dann die Partitionstabelle die Werte für die andere Blockgröße hat (bei "fdisk" kann mit mit "-b" gezielt eine andere Blockgröße zum Anzeigen der Partitionsdaten angeben, hier mal ein Beispiel wie das Aussieht bei so einer kopierten Festplatte an unterschiedlichen Kontrollern:
sudo fdisk -l /dev/sdi
Festplatte /dev/sdi: 2,7 TiB, 3000592982016 Bytes, 732566646 Sektoren
Einheiten: Sektoren von 1 * 4096 = 4096 Bytes
Sektorgröße (logisch/physikalisch): 4096 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x00000000
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdi1 1 4294967295 4294967295 16T ee GPT
man beachte die 16 Terabyte große Partition auf einer nur 3 TB großen Festplatte
und die gleiche mit der geänderten Sectorgröße beim Auslesen:
sudo fdisk -b 512 -l /dev/sdi
Festplatte /dev/sdi: 2,7 TiB, 3000592982016 Bytes, 5860533168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: AE8AC505-F114-4E81-A852-CEC50483A3F7
Gerät Anfang Ende Sektoren Größe Typ
/dev/sdi1 2048 5860532223 5860530176 2,7T Linux-Dateisystem
und es stimmt wieder, was in den Partitionsdaten steht bis auf die physikalische Sectorgröße.
|
themroc
Anmeldungsdatum: 5. November 2006
Beiträge: 1550
Wohnort: JWD bei Berlin
|
Und ich verstehe nicht, warum Du dd zum clonen genommen hast? Das ist doch bei SSDs völlig ineffektiv. Mounte die beiden SSDs mit einer Live-CD und lasse rsync den Job machen:
sudo rsync --stats --progress --numeric-ids -axAhHSP /mnt/alt/ /mnt/neu Siehe auch Ubuntu umziehen (Abschnitt „Daten-mit-dem-Programm-rsync-kopieren“)
|