Umzug von HDD zu SSD mit minimalen Arbeitsaufwand

[Esc]

Hallo,

Ich will mir in paar Wochen endlich eine SSD gönnen. (160GB Intel X25-G2..) Mal mein T60 pimpen!

Bisher besitze ich eine Samsung 320GB Festplatte, mit einer 60 GB Partition für Windows Vista (da ich genau ein Programm brauche, dass partout nicht laufen möchte, auch nicht unter Virtualbox, itunes + iphone Firmware) und der Rest Linux. Hab gelesen, dass es auch ne Intel-Toolbox gibt, mit der man dann eine neue Firmware auf die SSD-Controller laden kann. Daher hätt ich ja noch ein Grund, Windows nativ drin zu haben.

Meine Festplatte ist mit über 160GB an Daten gefüllt, sodass ich erstmal bisschen aufräumen müsste, bevor ich umziehe. Dies würde kein Problem sein und ist sicher machbar. Hab mit der Zeit viel Mist hier angesammelt.

Die Linux Partition ist ext3 und die Windows Partition ist NTFS. Sind den beide Formate für eine SSD empfehlenswert?

Und nun meine eigentliche Frage: Wie kann ich das gesamte Festplattenabbild auf die SSD übertragen? Ich habe momentan einfach keine Zeit für Neuinstallationen und würde gerne dann alles so haben, wie im aktuellen Zustand. Ich habe Anleitungen gefunden, frage mich aber, ob da auch die Windows-Partition mitbeachtet wurde.

 

[linrunner]

Hi,

ich ziehe Linux immer mit [font='Courier New, Courier, mono']rsync -ax[/font] von einen Rettungssystem aus um, aber das war's glaube ich nicht was du suchtest... :whistling:

Schau Dir mal Clonezilla Live an. Dort gibt es allerdings die Einschränkung, daß die Zielpartition nicht kleiner sein kann. Aber vielleicht hast Du die Möglichkeit vor dem Klonen zu verkleinern.

Solange es sich nur um Ext3 (kein LVM im Spiel?) und NTFS handelt, müßte Clonezilla auch direkt mit dem Filesystem umgehen können. Das ist bei einer SSD als Ziel ja wichtig, damit nur die benutzten Sektoren kopiert werden.

 

[mikar]

Intel behauptet, dass ihre SSDs 5 Jahre lang mit 20 GB pro Tag beschrieben werden können, bis die Disk aufgibt.
Wenn man über 20 GB an einem Tag schreibt, setzt afaik ein besonderer Mechanismus ein, der Abnutzung verhindern soll. Die Konsequenzen dieses Mechanismus sind mir nicht bekannt, aber für Haltbarkeit wird wohl irgendetwas eingetauscht werden müssen (Geschwindigkeit, Datensicherheit, ..?).

Auch wenn Intel-SSDs eine Klasse für sich sind, halte ich es nicht für empfehlenswert eine neue SSD gleich zu 50% und mehr mit Daten zu füllen und dabei ~80 GB und mehr zu schreiben.
Lieber in Ruhe aufsetzen und erstmal nur die wichtigsten Daten draufziehen.

Ansonsten wäre CloneZilla aber auch mein Werkzeug der Wahl.

Grüße,
mikar

 

[paolo]

Ueberpruefe das Alignment wenn du die HDD gespiegelt hast (ich mach das immer mit Acronis)

[T400] [gelöst] SSD: Stimmt das Alignment?

schöne Platte hast du dir da ausgesucht :thumbup:

 

[mikar]

Sinnvoller wäre es, das Alignment vorher zu prüfen. Ein einfaches sudo fdisk -lu /dev/sda reicht da. Der Startsektor sollte ein Vielfaches von 64, 128 oder besser 512 sein. Heads und sectors kannst du ja auch mal posten, aber ich nehme an, dass es 255 heads und 63 sectors/track sind.
Alignment bei Dual-Boot bereitet mir momentan allerdings Probleme, da Windows irgendetwas mit /dev/sda1 anstellt, was das alignment in Form von CHS verwirft. Hat man eine extended partition, so wird das alignment der logischen Partitionen auch noch einmal um 32 KB verschoben. Ziemlich messy insgesamt. Ich versuche heute nochmal bei meinem Laptop das alignment richtig hinzubekommen, habe schon ein oder zwei Ideen. Gestern beim HTPC hat's leider nicht so richtig geklappt.

Ich kann aber entwarnen, die Intel-SSDs profitieren kaum vom Alignment. Zumindest nicht in einer Weise, wie es bei manchen SSDs der ersten Generation der Fall ist (Stottern und Performanceeinbrüche bei falschem Alignment).

Grüße,
mikar

 

[Esc]

Danke für eure Hinweise.

Platte /dev/sda: 320.0 GByte, 320072933376 Byte
255 Köpfe, 63 Sektoren/Spuren, 38913 Zylinder, zusammen 625142448 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Disk identifier: 0x99b5207f

Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 * 2048 122882047 61440000 7 HPFS/NTFS
Partition 1 endet nicht an einer Zylindergrenze.
/dev/sda2 122897250 617024519 247063635 83 Linux
/dev/sda3 617024520 624832109 3903795 82 Linux Swap / Solaris

Ist das Alignment gut? 2048? Auf die Swap-Partition werde ich getrost verzichten können. Irgendwie erscheint sie mir in Zeiten von mehr als 1GB-Ram unnötig und zweitens wird es ja meines Wissens nach für SSDs nicht empfohlen, eine anzulegen. (obwohl die Swap bei mir sowieso seltens beschrieben wird..)

 

[mikar]

Das Offset, also der Startblock von 2048 ist okay.
Allerdings sind 255 heads * 63 sectors/track afaik nie ideal.

Was gibt denn "sudo fdisk -l /dev/sda" aus?
Bei dir müsste es so aussehen:

Units = cylinders of 16065 * 512 = 8225280 bytes

Ob das alignment stimmt, kann man mit ((partition offset)*(disc sector size))/(stripe unit size) ausrechnen (siehe auch hier). Ich weiß leider nicht, was Windows Vista/7 als stripe size benutzt. Bei NTFS kreirt durch Windows Server 2003 sind es 128 KB, bei den meisten Linux-Dateisystemen afaik standardmäßig 4(?) KB.
Mit 128KB wären das bei dir (2048*512)/131072=8, also integer, also gut, was allerdings auch auf 4KB zutreffen würde.
Wie man von CHS, blocks und Offset rechnerisch aufs konkrete alignment kommt, habe ich leider noch nicht herausgefunden. Wenn hier jemand mehr weiß, immer raus damit.
Anzeigen lassen kannst du dir dein Alignment mittels AS SSD Benchmark, welches dir gleich noch sagt, ob das Alignment gut oder schlecht ist. Mit Windows-Boardmitteln geht das offenbar mit Diskpart, indem man das Offset mit 2 multipliziert. Ob das so richtig ist, weiß ich leider nicht. Ich komme bei dir nämlich auf ein alignment von 8032,5 KB, zumindest wenn ich diese Werte als Grundlage nehme: "Units = cylinders of 16065 * 512 = 8225280 bytes". Bei mir sind's nämlich "Units = cylinders of 1024 * 512 = 524288 bytes", was einem Alignment von 512 KB entspricht, welches ich bewusst mittels Fdisk so angelegt habe und mir von AS SSD Benchmark so auch bestätigt wird.

Grüße,
mikar

 

[yatpu]

ich hab meine ssd mit fdisk -H 64 -S 32 /dev/sda partitioniert. also 64 köpfe und 32 sektoren pro spur. damit erhält man ein alignment auf 1 mb. wenn man zusätzlich noch lvm nimmt, sollte man dessen alignment auch noch anpassen, genauer gesagt die größe des metadaten-bereichs zwischen start des physical volumes und dem ersten logical volume. auch in mke2fs kann man noch etwas optimieren. die infos dazu hab ich aus dem blog von theodore ts'o dem maintainer von ext{2,3,4}. ich hab allerdings nicht, wie er, auf 512 kb, sondern 1 mb alignt, somit also andere werte benutzt. wie die genau sind, kann man sich zusammenreimen und bei lvm muss man etwas probieren. der grund dafür wird von theodore auch erklärt.

hier der link zum blogeintrag:
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/

wenn ich richtig informiert bin, macht vista das alignment auch korrekt. wenn man die ssd also mit vista partitioniert, sollte zumindest die positionierung der partitionen in ordnung sein.

 

[mikar]

Vista legt per Standard wohl ein Alignment von 64 KB an. Theodore Ts'o wählt als alignment glaube ich 6272 KB, sodass jeder cylinder 49*128 KB groß ist.
Allerdings blicke ich bei seiner Rechnung nicht so ganz durch.
Er setzt 224 (32*7) heads und 56 (8*7) sectors an, sodass er auf 12544 (256*49) sectors/cylinder kommt. Woher kommt die 7?

 

[yatpu]

theodores einstellungen eignen sich für alignment auf 128 kb, 896 kb (7 * 128 kb) und 6272 kb (49 * 128 kb). für eine erase block größe von 128 kb passt das. ich hab lieber auf 1 mb alignt, da ich nciht weiß, wie groß die erase blöcke bei meiner ssd sind (solidata k5) und darauf spekuliert hab, dass sie nicht größer als 1 mb ist. das wichtigste ist meines erachtens nach, dass die partitionen wenigstens auf 4 kb ausgerichtet sind, da dies die kleinste schreibbare einheit im inneren der ssd ist, genau wie bei den gerade erscheinenden festplatten mit 4kb-sektoren (ears reihe von wd). so wird nämlich vermieden dass bei änderung eines sektors daten auf 2 physikalische sektoren verteilt werden müssen. ob ein alginment an erase blöcken ebenfalls nötig/sinnvoll ist, müsste mal untersucht werden. da ssd intern "sektoren" nach belieben hin- und hermappen, könnte es sein, dass alignment an erase blöcken nicht erforderlich ist. bis dahin gehe ich lieber auf nummer sicher und richte die partitionen und fs-strukturen an 1mb-zylindern aus. denn schaden tut das nicht.

 

[mikar]

Da du die Zahlen nun auch benutzt hast:
Wofür steht denn die 7, respektive die 49?

Ganz so sicher, dass die Erase-Blöcke der X25-M 128KB groß sind, bin ich mir auch nicht. Ich finde dazu jedenfalls kein offizielles Dokument. In Testberichten wird es allerdings ab und an erwähnt. Hier wird ab Seite 2 über die Größe der erase blocks spekuliert.

Grüße,
mikar

 

[yatpu]

theodores zylinder sind 49 * 128 kb groß ohne rest kann man nur "happen" von 128, 896 und 6272 kb darin unterbringen. das heißt, dass besagte konfiguration geeignet ist für erase blöcke von genau diesen größen. da aber i.d.r. nur potenzen von 2 verwendet werden, ist 128 kb die einzige sinnvoll erscheinende erase block größe, für die genanntes alignment geeignet ist. erase blöcke von 512 kb beispielsweise passen nicht restlos ist solche zylinder rein. es wird immer mindestens ein eraseblock pro zylinder in den jeweils nächsten zylinderreinreichen. daher eignet sich ein alignment auf 49 * 128 kb nur für 128 kb große erase blöcke oder auch für kleinere mit 32 oder 64 kb. bei blockgrößen ungleich 128, 896 oder 6272 kb werden auch wieder blöcke auf mehrere zylinder v erteilt.


edit:
daher bin ich lieber gleich auf 1 mb gegangen. die erste partition darf aber nciht mit de ersten zylinder beginnen, da sonst grub keinen platz mehr hat. daher fängt bei mir die erste partition bei zylinder 4 an.

 

[mikar]

War das an mich gerichtet? Mir ist nämlich immernoch nicht klar, woher die Zahlen 7 bzw. 49 kommen. Dass man sie in ein Verhältnis setzen kann und bestimmte Ergebnisse bekommt, ist mir klar, aber für das Benutzen der Zahl 7 muss es hier doch irgendeine Grundlage geben. Die einzige Verbindung, die ich sehe, ist: 512*56=28672=4096*7 bytes, also 56 Sektoren * 512 (auf Geräten mit 512 B Sektorengröße?) entspricht 7 mal 4096 (offenbar auf Geräten, die mit einer Sektorengröße von 4096 bytes arbeiten?). Bedeutet das, dass hinter der 7 ein Äquivalent für Sektoren steckt? Was bedeutet die Größe von 28672 bytes (=28 KB) für Geräte, deren Sektoren 4096 Bytes fassen, außer dass es ein Vielfaches dieser Sektorengröße ist. Könnte das was mit "tracks" zu tun haben?

:huh:

 

[Esc]

Ich verstehe nur Bahnhof ;(

 

[lucid]

[quote='Esc',index.php?page=Thread&postID=807977#post807977]Ich verstehe nur Bahnhof ;([/quote]

Falls es dich beruhigt: ich auch.

 

[linrunner]

Mir scheint, in der Zeit die man braucht um das optimale Alignment auszurechnen und umzusetzen, sind ThinkPad und SSD bereits völlig veraltet.

 

[yatpu]

die 7 und die 49 hast du, mikar, von theodore ts'o übernommen und hier ins spiel gebracht. und theodore wiederum hat sie benutzt um eine zylindergröße zu erhalten, die ein vielfaches von 128 kb beträgt. warum er aber nicht einfach mit 32 köpfen und 8 sektoren pro spur arbeitet, was ihm zylinder von 128 kb bescheren würde, kann ich dir nicht verraten. vielleicht wollte er keine derart kleinen zylinder haben.