staging.inyokaproject.org

Danke schonmal für die Starthilfe, ist bestimmt auch für andere im Wikiartikel später hilfreich.

LUKS Payload offset ist 2056 und somit 1 MiB. Jedoch gibt pvs für "1st PE" 192,00k aus. Dass sda1 auf Sektor 63 beginnt, und dies natürlich 2048 sein sollte, weiß ich. Aber wie kann ich sicher sein, dass im LVM das Alignment stimmt? Macht es Sinn, durch den Anfang der Partition die womöglich falschen 192k auszugleichen?

Gruß,

Kai

2048 wäre 1MiB, 2056 sind 1 MiB + 4k. Ob das nun schlimm ist oder nicht hängt davon ab ob die SSD intern mit 4k Blöcken arbeitet oder größer...

Deine Installation wird wohl älter sein wenn weder cryptsetup noch LVM nach 1MiB Grenzen ausgerichtet sind. Wenn du eine Festplatte hast auf die du die Daten auslagern kannst würde ich das einfach nochmal neu machen. Mit Partitionen, crypsetup, LVM alles nach 1MiB Grenzen.

Ah, der Zahlenunterschied war mir nicht aufgefallen. Auch bei 4k oder 8k Blockgröße der SSD sind ja 192k als Offset ganz ok. D.h. auch bei LUKS+LVM reicht es sicherzustellen, dass die Partition bei 2048 anfängt. Danke 😉

In meinem Fall ist die Blockgröße 8k, aber das ext4-Dateisystem benutzt 4k. Also ignoriere ich mal die Verschiebung von 1 MiB + 4k. Per dd sollte es möglich sein, die Partition zu sichern, eine neue bei 2048 anzulegen und dann wieder zurückzuschreiben.

Hola,

ich finde der Artikel bezieht sich zu einseitig auf MBR und dessen Partitionstabelle. Das mag zum Erstellungzeitpunkt wohl zugetroffen haben, aber ist diese umfangreiche Erklärung zu fdisk noch notwendig?

• Mittlerweile gibt es einen eigenen Artikel fdisk.

• Immer mehr Systeme kommen mit EFI und bei Dualboot muss die GPT eingesetzt werden, dazu gibt es auch gdisk.

Die Grundlagentabelle wurde wohl nie gepflegt.

Zumindest der Partitionieren-Teil mit fdisk sollte komplett entnommen werden. So wie es jetzt da steht führt das mMn nur zu mehr Verwirrung.

P.S. Ich habe keine SSD, also kann ich nichts zu den Ausführungen im Text sagen.

Peace.

RapaNui schrieb:

ich finde der Artikel bezieht sich zu einseitig auf MBR und dessen Partitionstabelle. Das mag zum Erstellungzeitpunkt wohl zugetroffen haben, aber ist diese umfangreiche Erklärung zu fdisk noch notwendig?

• Mittlerweile gibt es einen eigenen Artikel fdisk.

Wenigstens der Hinweis für Lucid mit dem nötigen Consolenbefehl sollte im Artikel bleiben.

• Immer mehr Systeme kommen mit EFI und bei Dualboot muss die GPT eingesetzt werden, dazu gibt es auch gdisk.

Lass dich nicht abhalten, entsprechende Hinweise auf --align einzubauen. Allerdings solltest du da mit Lucid testen, denn damals gab es die Option noch nicht, oder?

Die Grundlagentabelle wurde wohl nie gepflegt.

Was stimmt den nicht, ist doch alles aktuell? Ich war schon immer der Meinung, dass dafür eine Tabelle denkbar schlecht ist. Ein einfacher Hinweis auf Lucid und das alle anderen ohne Nacharbeit passen.

Zumindest der Partitionieren-Teil mit fdisk sollte komplett entnommen werden. So wie es jetzt da steht führt das mMn nur zu mehr Verwirrung.

In wie fern?

Hola,

Lass dich nicht abhalten, entsprechende Hinweise auf --align einzubauen. Allerdings solltest du da mit Lucid testen, denn damals gab es die Option noch nicht, oder?

Da kann ich z.Zt. nichts testen, da RapaNui schrieb:

P.S. Ich habe keine SSD, also kann ich nichts zu den Ausführungen im Text sagen.

Lt. Dokumentation macht fdisk Vers. 2.17.2 dieses Alignment, mehr kann ich z.Zt. dazu nicht sagen.

stfischr schrieb:

Die Grundlagentabelle wurde wohl nie gepflegt.

Was stimmt den nicht, ist doch alles aktuell? Ich war schon immer der Meinung, dass dafür eine Tabelle denkbar schlecht ist. Ein einfacher Hinweis auf Lucid und das alle anderen ohne Nacharbeit passen.

Das meinte ich wohl mit "nicht aktuell", es wurde eine 4zeilige Tabelle aufgebaut, die nur einen ersten Eintrag hat.

• Das sieht für mich so aus, dass der Artikel nicht weiter gepflegt wurde - trotz Getestet-Block.

• Das sieht so aus, dass man das korrekte Alignment nur mit fdisk erreicht, da: Korrekt ausgerichtetes Alignment kann durchgeführt werden mittels:

Zumindest der Partitionieren-Teil mit fdisk sollte komplett entnommen werden. So wie es jetzt da steht führt das mMn nur zu mehr Verwirrung.

In wie fern?

• Der Eindruck nur fdisk verstärkt sich noch dadurch, dass dieses PGM ins kleinste nochmals erklärt wird.

• Ich pers. finde es verwirrend, wenn im Abschnit Partitionieren im Terminal extra die Einrichtung von Partitionen mit nur einem Programm beschrieben wird, welches bei einer anderen Partitionstabelle (GPT) nur mit Fehler abbricht.

• Etwas ähnliches bei SSD/Alignment (Abschnitt „Alignment-ueberpruefen“). fdisk listet zwar die Partitionseinträge auf, aber es bringt auch einen Hinweis

   WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.

  und der ist, zumind. bei nicht Englischkennern, verwirrend. Ok, das Auflisten könnte man auf GNU Parted umstellen oder ergänzen.

• Die viel beschworene Redundanz. Es gibt mittlerweile einen Artikel zu fdisk, der die Optionen und die Handhabung erklärt.

Es sollte ja auch nur ein Hiweis darauf sein, dass der Artikel eben einseitig auf MBR/MPT abzielt und die Nutzer mit einer GPT (z.B. nur SSD + EFI) außen vor lässt - eben rein subjektiv.

RapaNui schrieb:

Da kann ich z.Zt. nichts testen, da

Naja um Alignment zu testen, braucht man keine SSD, jeder beliebige Datenträger eignet sich dazu (auch virtuelle in KVM z.B.), man muss nur kontrollieren, ob sich der Startsektor der jeweiligen Partition durch 8 teilen lässt.

Das meinte ich wohl mit "nicht aktuell", es wurde eine 4zeilige Tabelle aufgebaut, die nur einen ersten Eintrag hat.

Vielleicht äußert sich UbuntuFlo mal dazu, der hat die Tabelle gemacht. Ist aber möglich das er sich nicht so schnell meldet, aus privaten Gründen. Von mir aus kann die Tabelle wie gesagt gerne weg.

• Die viel beschworene Redundanz. Es gibt mittlerweile einen Artikel zu fdisk, der die Optionen und die Handhabung erklärt.

Bin auch der Meinung das der Artikel viel kürzer sein könnte, früher stand das glaube nicht im fdisk Artikel, daher war das hier so ausführlich gemacht worden.

Es sollte ja auch nur ein Hiweis darauf sein, dass der Artikel eben einseitig auf MBR/MPT abzielt und die Nutzer mit einer GPT (z.B. nur SSD + EFI) außen vor lässt - eben rein subjektiv.

Wenn du bereit wärst, würde ich mit dir zusammen den Artikel in ner Baustelle überarbeiten, ich habe zu bieten SSD und MBR Erfahrung, mir fehlt GPT und EFI (Hardware).

Ich würde mich dann als Beispielprogramm auf parted einigen, da das beide Partitionstypen beherrscht.

Aufbau wäre dann folgender:

• Einleitung wie bisher

• Ubuntu ab 10.10 macht alles automatisch

  • Wie kann ich das überprüfen?

  • Wie kann ich das unter Lucid prüfen?

• Anleitung zum Partitionieren unter Lucid mit parted (nur der alignment relevante Teil für den Rest gibts nen Link auf den parted-Artikel)

Huhu!

Die Tabelle hatte auch mal Inhalt 😀 Dieser wurde hier zerstört. Ich repariere das gleich mal.

Es gab damals noch keinen fdisk-Artikel im Wiki. Daher wurde das alles hier verewigt. Wenn es selbigen aber nun gibt, kann der ganze redundante Teil hier raus und nach fdisk verlinkt werden.

Ab April 2013 fliegt zumindest die Lucid-Desktopversion raus. Bleibt nur noch die Serverversion bis April 2015 übrig. Da müsste man nochmal in sich gehen, ob man extra dafür noch den Lucid-Teil pflegt…

Wenn Ihr Hand anlegen wollt – nur zu! Ich komme, wie stfischr schon schrieb, zurzeit nicht dazu. Auch zu EFI und Co kann ich mangels Einsatz nichts Erhellendes beitragen.

Liebe Grüße,

Flo

UbuntuFlo schrieb:

Ich repariere das [die Tabelle] gleich mal.

Done!

Liebe Grüße,

Flo

stfischr schrieb:

Wenn du bereit wärst, würde ich mit dir zusammen den Artikel in ner Baustelle überarbeiten, ich habe zu bieten SSD und MBR Erfahrung, mir fehlt GPT und EFI (Hardware).

Ich gestehe Euer Ehren: Ich bin auf den Artikel gestoßen, da ich etwas zum Alignment wissen wollte ☺ Vielleicht ist es hilfreich beim Überarbeiten, dass ich noch einiges (vieles) hinterfrage, daher ok.

• Sofern die jüngeren Artikel zu fdisk, gdisk aber auch GNU Parted/GParted aussagefähig genug sind, könnte man das Partitionieren komplett entnehmen bzw. kurz in eine Tabelle der Linux-PGM packen, etwa so:

Damit würden man dann auch die derzeitige Tabelle, die UbuntuFlo korrigiert hat, erschlagen.

• Zu GPT gibt es nicht allzu viel zu sagen, außer dass es sich immer um primäre handelt. Hier bräuchte man also eine Auflistung MBR/GPT:

  • Warum zwei Typen,

  • kurzer Unterschied und

  • worauf achten (z.B. MBR=erweiterte nicht wichtig).

• Die Experten-Info ist mMn fundamental für den Hintergrund, daher auf Anfänger abstellen.

  • Nur auf SSD beziehen oder auch der Hinweis zu RAID?

• Einleitung bzw. Grundlagen würde ich mehr ausbauen. Wer weiß ob der TK-Server morgen noch existiert.

  • logische/physische Einheiten, sprich Sektoren.

  • Was ist wichtig - die 4 Kib.

  • Wie sieht das bei anderen Platten aus (512 Byte - 8 KiB).

  • Wie berechnet man das am einfachsten - Beispiel.

• Alle Auflistungen sollte man mit parted-batch machen (verarbeitet alle Tabellentypen).

  • Evtl. Gegenüberstellung: Listen mit GB und mit GIB - zum Verständnis.

  • Ob man das Partitionieren nochmals mit Konsolprogramm und/oder GUI kurz aufgreift kann man dann sehen.

• Wie kann ich überprüfen mit Beispielen:

  • Korrekte Auflistung mit parted (im Batchmodus nur eine Platte möglich).

  • Evtl. Einzeiler um alle Platten zu prüfen.

• Macht ein Beispiel des nachträglichen Bereinigens Sinn? z.B.:

  sudo parted -s /dev/sdX unit s resize 1 2048 NNNN

Und bei Allem immer wieder: Rechnen, rechnen, rechnen (lassen) ...

Saludos aus Chile

RapaNui

Ich werde mich morgen Abend mehr damit beschäftigen, heute habe ich keine Zeit.

RapaNui schrieb:

Vielleicht ist es hilfreich beim Überarbeiten, dass ich noch einiges (vieles) hinterfrage, daher ok.

Das ist schonmal sehr hilfreich, weil da fällt mir auf, dass wir keinen Artikel zu Alignment auf Festplatten haben, heutzutage gibt es ja fast nurnoch 4K Platten zu kaufen. Von daher würde ich den Artikel etwas allgemeiner fassen.

• Sofern die jüngeren Artikel zu fdisk, gdisk aber auch GNU Parted/GParted aussagefähig genug sind, könnte man das Partitionieren komplett entnehmen bzw. kurz in eine Tabelle der Linux-PGM packen, etwa so:

PGM	Konsole/GUI	Alignment ab ... realisiert	Hinweise
GParted	GUI	Version ?? (seit Lucid 10.04)	Da müssen wohl Menuepunkte eingestellt sein/werden?
fdisk	Konsole/ncurses	Version 2.17.2 (seit Lucid 10.04)	Optionen: -c -u benutzen erster Sektor auf 2048 abstellen/prüfen
gdisk	Konsole/ncurses	....

Damit würden man dann auch die derzeitige Tabelle, die UbuntuFlo korrigiert hat, erschlagen.

Könnte man so ungefähr machen, allerdings gibt es -u bei späteren fdisks garnicht mehr (ist standard).

• Zu GPT gibt es nicht allzu viel zu sagen, außer dass es sich immer um primäre handelt. Hier bräuchte man also eine Auflistung MBR/GPT:

  • Warum zwei Typen,

  • kurzer Unterschied und

  • worauf achten (z.B. MBR=erweiterte nicht wichtig).

dafür würde ich auf Partitionierung/Grundlagen verweisen

• Die Experten-Info ist mMn fundamental für den Hintergrund, daher auf Anfänger abstellen.

Ja denke als Hinweis ist es besser.

• Nur auf SSD beziehen oder auch der Hinweis zu RAID?

Raid ist ein komplexes Thema für sich und sollte im entsprechenden Artikel behandelt werden, 4K Festplatten dagegen hier ...

• Macht ein Beispiel des nachträglichen Bereinigens Sinn? z.B.:

  sudo parted -s /dev/sdX unit s resize 1 2048 NNNN

wäre nicht schlecht, habe ich aber noch nie getestet, wird wohl auf ein bisschen gefrickel in der VM rauslaufen.

Zur Diskussion:

Bei den neuesten SSD's wird dieser Artikel wohl ungültig!

Bisher haben wir unter "Alignment" die Ausrichtung an 1 MiB-Grenzen verstanden und Partitionen entsprechend ausgerichtet. Dies stammt aus den Anfangszeiten, als die (erase)block size nocht 128kiB betrug.

Aktuelle NAND-Flash (Intel 25nm und 20nm) haben jedoch schon block sizes von 2 MiB und demnächst sogar 8MiB, s. hier. Dann muß man anders partitionieren!!!

Aktuelle Partitionierunstools lassen die erste Partition bei Sector 2048 beginnen, das ist im Moment noch ok, aber bei mehreren Partitionen reicht das standardmäßige 1MiB-Alignment schon heute nicht mehr aus!

P.S.: mir kam die Info auch erst zu Gesicht, als ich für meine Intel S3500 SSD mit 20nm Chips die eraseblock size gesucht habe. Eventuell war das sogar ein Grund, warum meine Intel 520 SSD mit 25nm Chips ab und zu zu Freezes geführt hat (mit 4 Partitionen nur 1MiB aligned) ???

Die Erase Block Size spielt praktisch keine Rolle. Bitte beachte daß der von der Wikiseite verlinkte "Aligning filesystems to an SSD’s erase block size" schon 5 Jahre alt ist und sich noch auf SSD ohne TRIM bezieht.

Ein 8MiB Align wirst du nie hinbekommen, egal was du machst. Das ist einfach zu groß. Klar, du kannst die Partition auf 8MiB legen, aber meinst du, das Dateisystem wirft für jede Datei 8MiB weg nur damit die Dateien selbst auch jeweils aligned sind?

Darum gehts nämlich beim Alignment eigentlich, wenn du auf einer Festplatte mit 4k Sektoren die Partition bei 63 losgeht, dann ist durchweg jede einzelne Datei auf den letzten 512 Byte eines jeden 4k Sektors und jeder Zugriff >512 byte erfordert das unnötige Lesen von einem zusätzlichen Sektor.

frostschutz schrieb:

... Darum gehts nämlich beim Alignment eigentlich, wenn du auf einer Festplatte mit 4k Sektoren die Partition bei 63 losgeht, dann ist durchweg jede einzelne Datei auf den letzten 512 Byte eines jeden 4k Sektors und jeder Zugriff >512 byte erfordert das unnötige Lesen von einem zusätzlichen Sektor.

Ok, war ein Gedankenfehler, man sollte dann nur den Satz zur erase block size korrigieren.

Lesen tun SSD's aber auch nicht Dateisystemblöcke von 4kiB, sondern nur komplette "pages" auf dem Flash. Das sind aktuell 8kiB (20 und 25nm Chips) und in Zukunft sogar 16kiB. Damit sinkt dann die 4k random read Rate weiter unter das maximal mögliche.

ingo2 schrieb:

frostschutz schrieb:

... Darum gehts nämlich beim Alignment eigentlich, wenn du auf einer Festplatte mit 4k Sektoren die Partition bei 63 losgeht, dann ist durchweg jede einzelne Datei auf den letzten 512 Byte eines jeden 4k Sektors und jeder Zugriff >512 byte erfordert das unnötige Lesen von einem zusätzlichen Sektor.

Ok, war ein Gedankenfehler, man sollte dann nur den Satz zur erase block size korrigieren.

Nicht ganz, habe es nur nicht zu Ende gedacht/formuliert:

Wenn ich bei nicht Block-aligned Partitionen (angenommen, es gibt mehrere Systeme auf der SSD) z.B. ein 'fstrim' absetze und anschließend die "garbage collection" mit dem Umsortieren anfängt, ist es kein gutes Gefühl, wenn dabei auch Blöcke mit Daten von Nachbar-Partitionen/Systemen mit bearbeitet werden. Das könnte eventuell sogar die Ursache für meine Probleme mit der Intel 520 SSD gewesen sein (Partitionen nur 1MiB aligned bei 2MiB Blockgröße), s. hier.

Viele Güße,
Ingo