Frage zum Alignment (SSD)

[owl102]

Im Netz ist zu lesen, daß man mittels "fdisk -S 32 -H 64" testen kann, ob die Partitionen auf 1MB "aligned", also ausgerichtet sind, da "-S 32 -H 64" eine Zylindergröße von 1MB vorgaukelt. Ich bin offensichtlich zu doof dazu, eine Partition anzulegen, die dieses Kritierum erfüllt. Was habe ich gemacht: Ich habe mir GParted geschnappt, welches per Default in MB rechnet, und (unter anderem) eine 60GB Partition an der Startaddresse 1MB angelegt, "fdisk -S 32 -H 64" sagt aber dazu:

Code: Alles auswählen

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           2       61441    62914560    7  HPFS/NTFS
Partition 1 does not end on cylinder boundary.
/dev/sda2           61442      244198   187142145    5  Extended
Partition 2 does not end on cylinder boundary.
/dev/sda5           61443       81907    20956160   83  Linux
/dev/sda6           81909       88869     7128064   82  Linux swap / Solaris
/dev/sda7           88871      244198   159055872   83  Linux

Wie kann eine Partition, die bei 1MB anfängt, und exakt 60GB bzw. 61440MB groß ist, hier zu der Meldung "Partition 1 does not end on cylinder boundary." führen?

Die anderen Partitionen habe ich mit dem Installer von Debian/Squeeze erstellt. Da wundert mich, daß die / Partition nicht am Anfang der Extended Partition liegt, sondern erst 1MB später anfängt. Wieso?

Und wie kann ich denn nun verlässlich herausfinden, ob alle meine Partitionen auf 1MB oder zumindest 512k aligned sind oder nicht?

[SubOptimal]

Hi,

die gesuchten Infos kann Dir fdisk selbst anzeigen. fdisk im interaktiven Modus starten. Da kannst Du mit folgenden Befehlen nachschauen.

x - wechselt in Expertenmodus
p - Partitionstabelle anzeigen, Anzeige erfolgt dann in Head/Sector/Cylinder für Start und Ende der Partition
r - wieder ins Hauptmenü zurück

SubOptimal

[owl102]

p - Partitionstabelle anzeigen, Anzeige erfolgt dann in Head/Sector/Cylinder für Start und Ende der Partition

Code: Alles auswählen

Disk /dev/sda: 64 heads, 32 sectors, 244198 cylinders

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 1 80  32  33    0 254  63 1023       2048  125829120 07
Partition 1 does not end on cylinder boundary.
 2 00 254  63 1023 254  63 1023  125833214  374284290 05
Partition 2 does not end on cylinder boundary.
 3 00   0   0    0   0   0    0          0          0 00
 4 00   0   0    0   0   0    0          0          0 00
 5 00 254  63 1023 254  63 1023          2   41912320 83
 6 00 254  63 1023 254  63 1023       2048   14256128 82
 7 00 254  63 1023 254  63 1023       2048  318111744 83

Irgendwie stehe ich gerade mächtig auf dem Schlauch, denn ich sehe nicht, wie mir das weiterhilft, denn 125829120 läßt sich perfekt durch 2048 teilen... Was also stimmt mit Partition 1 nicht?

Ich habe mir mal als Alternative von allen Partition durch GParted "Erster Sektor", "Letzter Sektor" und "Sektoren insgesamt" anzeigen lassen, und alles durch 2048 geteilt. Dabei ist aber auch wiederum nur das herausgekommen, was ich schon vorher beobachtet hatte: Alle "realen" vier Partitionen liegen auf 1MB-Grenzen (sowohl Start als auch Ende), und zwischen allen Partitionen ist ein MB Platz, lediglich die erweiterte Partition fängt quasi 2 Blöcke zu früh an (was aber hoffentlich keinen großen Geist stört!?).

"Partition 1 does not end on cylinder boundary." und "Partition 2 does not end on cylinder boundary." kann ich also immer noch nicht erkennen, lediglich "Partition 2 does not start on cylinder boundary." würde ich verstehen.

[SubOptimal]

Hi,

sieht irgendwie seltsam aus. Anfang und Ende der Partitionen >1 beginnen und enden da, wo Partition 1 endet.
Allerdings wird sich fdisk daran stören, dass Du 64 Köpfe vorgibst, aber in der Partitionstabelle Partitionen auf Kopf 254 anfangen/enden.

Was meint denn fdisk selbst dazu? "v" im Expertenmodus?
Und wenn Du fdisk einfach mal ohne die Angabe für Sektoren und Köpfe aufrufst?

... (was aber hoffentlich keinen großen Geist stört!?).

Fall nur nicht vom Dach, Karlson.

SubOptimal

[rendegast]

Beim ersten Tool fehlt die Sektorangabe,
denn Du möchtest aligned sehen:

Code: Alles auswählen

fdisk -luc /dev/sda

Dito beim zweiten Tool

Code: Alles auswählen

parted /dev/sda unit s print free

Der Test:

Code: Alles auswählen

parted /dev/sda align-check min
parted /dev/sda align-check opt        <---------

aligned-Anlegen mit parted:

Code: Alles auswählen

parted --align opt /dev/sda mktable [msdos|gpt]
parted --align opt /dev/sda mkpart

fdisk -S 32 -H 64
<->
Disk /dev/sda: 64 heads, 32 sectors, 244198 cylinders

Wohl nicht die Zylinder, auf die sich die Fehlermeldung(?) bezieht:

# fdisk -l -S32 -H64 /dev/sda

Disk /dev/sda: 80.1 GB, 80060424192 bytes
64 heads, 32 sectors/track, 76351 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xcf14cf14
...


# fdisk -lu -S32 -H64 /dev/sda

Disk /dev/sda: 80.1 GB, 80060424192 bytes
64 heads, 32 sectors/track, 76351 cylinders, total 156368016 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xcf14cf14
...




# fdisk -lu /dev/sda

Disk /dev/sda: 80.1 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders, total 156368016 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xcf14cf14
...


# fdisk -l /dev/sda

Disk /dev/sda: 80.1 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xcf14cf14
...

Code: Alles auswählen

$ echo $(( 16065 * 512  ))
8225280

ist ungleich den genauen 8MB:
$ echo $(( 8*1024*1024 ))
8388608

fdisk rechnet bei der Meldung wohl immer noch mit der ursprünglichen Zylindergröße.

Wenn Du fdisk aligned verwenden willst, so IMMER 'fdisk -u' (+ genauem Rechnen ),
besser 'fdisk -uc' -> dann wird auch ohne Rechnen 1MB-align verwendet, und nicht 1s-align
(Mit '-H64 -S32 -c' gelingt mir nur die erste Partition 1M-aligned, dann nur noch 1s-aligned.)

Und (g)parted mußt Du spätestens für gpt-partitionierte Platten verwenden.




Bemerkung zu GParted:
Hat mir beim Anlegen-Apply mehrerer Partitionen kleine unbenutzte Bereiche dazwischen angelegt.
Das passierte nicht beim sequenziellen Anlegen der Partitionen.

[badera]

Nur aus Interesse: Wozu dieses Alignement auf 1MB?

[rendegast]

win7/vista hat einen quasi-Standard gesetzt.

[badera]

Und was bringt es? Was sind die Konsequenzen bei Win7/Vista, wenn man sich nicht daran hält? Und was hat es mit SSDs zu tun?
Dumme fragen; ich sehe wohl den springenden Punkt nicht!?

[Danielx]

Und was bringt es? Was sind die Konsequenzen bei Win7/Vista, wenn man sich nicht daran hält? Und was hat es mit SSDs zu tun?
Dumme fragen; ich sehe wohl den springenden Punkt nicht!?

Damit die Blockgrenzen des Dateisystems und die Blockgrenzen der SSD (oft: Blockgröße SSD > Blockgröße HDD) ausgerichtet sind.
Ist das nicht so, dann kann es passieren, dass die SSD intern zwei Blöcke beschreiben muss, obwohl bei richtiger Ausrichtung nur ein Block beschrieben werden müsste.
Das würde dann die Geschwindigkeit und die Lebensdauer der SSD verringern.

Gruß,
Daniel

[rendegast]

Passender Link:
http://wiki.aptosid.de/index.php/Optimi ... 3%BCr_SSDs

Es ist natürlich sinnvoll, dass die Blöcke des Filesystems mit denen der SSD zusammenpassen:
Überlappt ein Filesystemblock zwei SSD-Blöcke,
so müssen beim Löschen doppelt so viele SSD-Blöcke behandelt werden.

Die SSD-Blockgröße muss unter dem Suchbegriff "NAND Erase Block Size" recherchiert werden.
Bei der INTEL-25M G2 ist das 512 kB, also 512*1024 = 524288 Byte.

fdisk legt standardmäßig das Schema 255 (Köpfe) * 63 (Sektoren) * 512 Byte Sektorgröße = 8225208 Byte = 8032 kByte je Zylinder fest. Das passt also nicht zur SSD-Blockgröße.

[blackm]

Ist das vergleichbar mit dem Trim Befehl unter Windows? Oder ist das noch wieder etwas anderes?

[Danielx]

Ist das vergleichbar mit dem Trim Befehl unter Windows? Oder ist das noch wieder etwas anderes?

Das ist etwas anderes, siehe:
http://de.wikipedia.org/wiki/TRIM

Gruß,
Daniel

[blackm]

Danke

Wie verhält sich das den mit Squeeze. Wenn ich das richtig gelesen habe, dann wird es mit 2.6.32 ausgeliefert und TRIM ist erst ab 2.6.33 im Kernel drin.

Weiß jemand ob der entsprechend gepatcht ist so das der Squeeze Kernel die Funktion unterstützt?

[badera]

Ja, es wird unterstützt! Es gibt hier einen Beitrag, der das schön belegt. Allerdings finde ich ihn gerade nicht.
Ich selbst habe auch Squeeze im Einsatz mit einer SSD und kann jedenfalls die Partition mit "discard" mounten.

Code: Alles auswählen

adrian@opteron:~$ uname --all
Linux opteron 2.6.32-5-amd64 #1 SMP Fri Dec 10 15:35:08 UTC 2010 x86_64 GNU/Linux

[badera]

Und was bringt es? Was sind die Konsequenzen bei Win7/Vista, wenn man sich nicht daran hält? Und was hat es mit SSDs zu tun?
Dumme fragen; ich sehe wohl den springenden Punkt nicht!?

Damit die Blockgrenzen des Dateisystems und die Blockgrenzen der SSD (oft: Blockgröße SSD > Blockgröße HDD) ausgerichtet sind.
Ist das nicht so, dann kann es passieren, dass die SSD intern zwei Blöcke beschreiben muss, obwohl bei richtiger Ausrichtung nur ein Block beschrieben werden müsste.
Das würde dann die Geschwindigkeit und die Lebensdauer der SSD verringern.

Wie ist das denn, wenn man z.B. eine SSD mit gparted mit einer einzigen Partition zu 100% belegt und formatiert? Kommt es sich noch auf das FS draufan? Ist dann das nicht einfach automatisch richtig? Oder wenn man bei der Installation von Windows die Partitioniererei Windows überlässt? Oder auch bei der Installation von Debian die Partitioniererei dem Debian-Installer überlässt? Ich bin wirklich etwas erstaunt, dass man da als Benutzer doch noch so technisch darauf achten muss, dass da alles optimal abläuft!!!

[blackm]

Vielen Danke

Ich überlege in mein Netbook eine SSD einzubauen....und das dann mit Squeeze....dann ist meine Vorfreude um so größer

[owl102]

Erstmal möchte ich mich für die vielen Antworten auf meinen Ursprungsbeitrag bedanken! Leider habe ich noch keine Zeit gefunden, die ganzen Tipps und Hinweise durchzuarbeiten, ich hoffe, daß ich dieses Wochenende endlich dazu komme.

Wie ist das denn, wenn man z.B. eine SSD mit gparted mit einer einzigen Partition zu 100% belegt und formatiert? Ist dann das nicht einfach automatisch richtig?

Wenn man ein aktuelles GParted verwendet und nicht an den Einstellungen herumbriegelt, dann wird die Partition mit einem Abstand von 1MB vom Anfang angelegt (steht auch im Dialog, wenn man eine neue Partition anlegt) und ist damit "aligned". Ansonsten nicht, weil die erste Partition traditionell nicht ganz am Anfang anfängt, u.a. weil diverse Bootloader Daten zwischen MBR und erster Partition ablegen.

Oder wenn man bei der Installation von Windows die Partitioniererei Windows überlässt?

Windows 7 erkennt SSDs und partitioniert dann richtig. Wenn man vorher keine SSD hatte und nun umrüstet, hat man allerdings ein Problem, wenn man Windows 7 nicht komplett neu aufsetzen möchte, weil es ohne SSD eben anders partitioniert.

Oder auch bei der Installation von Debian die Partitioniererei dem Debian-Installer überlässt?

Das werde ich ausprobieren, sobald Squeeze stable ist. Ich hatte meine Squeeze-Version aus "weekly-build" und die verwendet noch den "alten" Installer und der macht es - wie ich merken mußte - nicht automatisch richtig.

[Cronchions]

Hallo zusammen,

wie wichtig ist den die Partitionierung einer aktuellen SSD unter Squeeze? Ich habe am Freitag eine OCZ Vertex 2 120 GB in mein Laptop verbaut und Squeeze installiert. Dabei habe ich nicht auf die Partitionierung geachtet und frage mich nun ob mit der SSD wirklich was schiefehen kann?
Hier die Ausgebe von fdisk -luc /dev/sda:

Code: Alles auswählen

/dev/sda1   *        2048    39063551    19530752   83  Linux
/dev/sda2        39065598   234440703    97687553    5  Extended
/dev/sda5        39065600   117188607    39061504   83  Linux
/dev/sda6       117190656   234440703    58625024   83  Linux

Wie mir scheint startet die /dev/sda1 bei Zylinder 2048 und nicht bei 1 oder 0. Somit muss wohl der Squeeze-Installer alles richtig gemacht haben?

Hoffe das mir jemand die Frage beantworten kann.

Danke und Grüße,

Cronchions

[rendegast]

Bis auf das logische Konstrukt "erweiterte Partition" sind die beschreibbaren Bereiche aligned, also ok.

Kannst Du Dir nach Verfolgen der Threads auch selbst beantworten.

Code: Alles auswählen

parted /dev/sda align-check [min|opt]

[Cronchions]

Bis auf das logische Konstrukt "erweiterte Partition" sind die beschreibbaren Bereiche aligned, also ok.

Kannst Du Dir nach Verfolgen der Threads auch selbst beantworten.

Code: Alles auswählen

parted /dev/sda align-check [min|opt]

Heißt also für mich die erweiterte Partition zu löschen und nur noch eine Partition auf der Platte zu erstellen. Offensichtlich macht das Partitionieren auf einer SSD nicht mehr wirklich Sinn, somit kann man diese Altlasten über Bord werfen Jedenfalls macht der Squeeze-Installer bei der Installation alles richtig.

Stellt sich mir aber immer noch die Frage, ob Alignment auch bei aktuellen SSD-s die Lebensdauer beeinträchtigt?

Danke und Grüße,

Cronchions.

[EDIT]Sollte man sich bei SSD-s auch Gedanken über das Dateisystem machen? Die Suchmaschinen spucken nur unbrauchbares dazu aus. Ich neige dazu EXT4 zu nutzen, obwohl einige behaupten dieses sei nur bedingt für SSD-s geeignet.[/EDIT]

[cosmac]

hi,

Bis auf das logische Konstrukt "erweiterte Partition" sind die beschreibbaren Bereiche aligned, also ok.

und

Jedenfalls macht der Squeeze-Installer bei der Installation alles richtig.

wie kommst du unter den Umständen zu folgendem Schluss?

Heißt also für mich die erweiterte Partition zu löschen und nur noch eine Partition auf der Platte zu erstellen. Offensichtlich macht das Partitionieren auf einer SSD nicht mehr wirklich Sinn

Warum das denn? Ein getrenntes /home für Desktop-Systeme z.B. ist noch genauso sinnvoll wie früher. Welchen Nachteil hätten denn deine drei Partitionen? Na gut, bei max. 4 Partitionen sollte man keine erweiterte anlegen, weil primäre im Katastrophenfall leichter zu reparieren sind, aber das gilt auch für normale Platten.

Stellt sich mir aber immer noch die Frage, ob Alignment auch bei aktuellen SSD-s die Lebensdauer beeinträchtigt?

davon sollte man immer ausgehen, man weiß ja nie, wie eine bestimmte SSD intern wirklich arbeitet. High-End-Modelle vertragen vielleicht ein Alignment auf 4K (8 Sektoren), aber sicher nicht auf einen einzelnen Sektor. Da kann man auch gleich 1MB (2048 Sektoren) verwenden, der Aufwand beim Partitionieren ist ja gleich.

Sollte man sich bei SSD-s auch Gedanken über das Dateisystem machen? Die Suchmaschinen spucken nur unbrauchbares dazu aus. Ich neige dazu EXT4 zu nutzen, obwohl einige behaupten dieses sei nur bedingt für SSD-s geeignet.

Natürlich ist ein Journal schlecht für SSDs, aber die Frage ist doch, ob mir meine Daten den etwas höheren Verschleiß¹ wert sind. Von Exoten mal abgesehen, stehen ext4, ext2 und fat zur Auswahl; ext3 vereinigt praktisch die Nachteile von ext2 und Journal; fat ist bei großen Dateien noch schonender² als ext2.

1) http://thunk.org/tytso/blog/2009/03/01/ ... erelatime/
2) http://beyondabstraction.net/2009/03/02 ... ournaling/

[Cronchions]

hi,

Bis auf das logische Konstrukt "erweiterte Partition" sind die beschreibbaren Bereiche aligned, also ok.

und

Jedenfalls macht der Squeeze-Installer bei der Installation alles richtig.

wie kommst du unter den Umständen zu folgendem Schluss?

Weil die erste Partition vom Installer angelegt und weitere von mir hinzugefügt wurden. Deswegen gehe ich davon aus, dass der Installer hier richtig arbeitet und die Partition ab dem 2048 Sektor anlegt.

Heißt also für mich die erweiterte Partition zu löschen und nur noch eine Partition auf der Platte zu erstellen. Offensichtlich macht das Partitionieren auf einer SSD nicht mehr wirklich Sinn

Warum das denn? Ein getrenntes /home für Desktop-Systeme z.B. ist noch genauso sinnvoll wie früher. Welchen Nachteil hätten denn deine drei Partitionen? Na gut, bei max. 4 Partitionen sollte man keine erweiterte anlegen, weil primäre im Katastrophenfall leichter zu reparieren sind, aber das gilt auch für normale Platten.

Sagen wir es mal so, welchen Vorteil habe ich durch das Anlegen von Partitionen bei einer SSD?

Sollte man sich bei SSD-s auch Gedanken über das Dateisystem machen? Die Suchmaschinen spucken nur unbrauchbares dazu aus. Ich neige dazu EXT4 zu nutzen, obwohl einige behaupten dieses sei nur bedingt für SSD-s geeignet.

Natürlich ist ein Journal schlecht für SSDs, aber die Frage ist doch, ob mir meine Daten den etwas höheren Verschleiß¹ wert sind. Von Exoten mal abgesehen, stehen ext4, ext2 und fat zur Auswahl; ext3 vereinigt praktisch die Nachteile von ext2 und Journal; fat ist bei großen Dateien noch schonender² als ext2.

1) http://thunk.org/tytso/blog/2009/03/01/ ... erelatime/
2) http://beyondabstraction.net/2009/03/02 ... ournaling/

Vielen Dank für die Links, werde ich mir dann genauer anschauen. Als Dateisystem verwende ich ext4

Mfg, Cronchions

[cosmac]

Sagen wir es mal so, welchen Vorteil habe ich durch das Anlegen von Partitionen bei einer SSD?

Genau den gleichen, wie bei einer konventionellen Platte: ich kann individuelle mount-Optionen und Dateisysteme verwenden, die Datensicherung wird übersichtlicher, bei Neuinstallation bleiben meine Daten unberührt, bei Fehlern ist nicht gleich alles kaputt...

[owl102]

Heißt also für mich die erweiterte Partition zu löschen

Wieso das? Ob die erweiterte Partition nun aligned ist oder nicht ist doch völlig Wurst, Hauptsache die "echten" Partitionen sind es. (Oder?)

Na gut, bei max. 4 Partitionen sollte man keine erweiterte anlegen, weil primäre im Katastrophenfall leichter zu reparieren sind

Gibt es eigentlich irgendeine Möglichkeit, die Partitionseinträge /dev/sda5-7 nach /dev/sda2-4 zu kopieren, um die erweiterte Partition loszuwerden, ohne die Partitionen löschen und neu anlegen zu müssen? (Auf die Schnelle habe ich bei fdisk keine passende Möglichkeit gefunden.)

[rendegast]

Code: Alles auswählen

/dev/sda1   *        2048    39063551    19530752   83  Linux
/dev/sda2        39065598   234440703    97687553    5  Extended
/dev/sda5        39065600   117188607    39061504   83  Linux
/dev/sda6       117190656   234440703    58625024   83  Linux

... irgendeine Möglichkeit, die Partitionseinträge /dev/sda5-7 nach /dev/sda2-4 zu kopieren,

Lösche die Partitionen (respektive deren Einträge) und lege sie an genau diesen Blöcken als primäre neu an.
Die Partitionierungsprogramme unterscheiden sich darin,
ob sie den kernel zum Neueinlesen der Partitionen on-the-fly veranlassen,
oder ob eventuell ein Neustart nötig ist.

IMO sollte das mit fdisk funktionieren.
Sicher ist es auf jeden Fall, die Aktion mit einem Live-System durchzuführen.