Ich will (endlich) mit Linux anfangen!

Interessant zu wissen. Wird die Einstellung auf der SSD hinterlegt und könnte man das mit einem Live-System vor einer Installation setzen? Oder wann macht man das am dümmsten?
Das kann man mit nvme-cli machen. Aber warum sollte man das wollen? Erstmal unterstützen das nicht alle NVME-SSDs. Dazu verlierst du alle Daten, die aktuell auf dem Laufwerk sind. Linux erkennt 512e Laufwerke und auch welche echte Blockgröße physikalisch genutzt wird und macht dann schon das Beste daraus. Irgendwelche Geschwindigkeitsvorteile bewegen sich im homöopathischen Bereich.

Falls man es doch machen will, das Arch Wiki hilft weiter:

 
Zuletzt bearbeitet:
Aber warum sollte man das wollen?


Fakt ist nun mal das ein 4K Format weniger CPU Last, weniger Controller Last ( bei der SSD ), weniger verschwendeten Speicher da weniger ECC Blöcke im Cluster selbst angelegt werden und dazu mehr Durchsatz beim read / write bringt.

Was halt nicht so cool ist das 1. die Platten natürlich einsprechen eingerichtet werden müssen, 2. demzufolge auch alle Daten flöten gehen und 3. alte Backups die mit 512e erstellt wurden nicht mehr kompatibel sind. Wenn man eh OC/UV bzw. Software gedönz mit seinem Rechner optimiert kann man die Leistung umsonst mitnehmen.

Bei den nvme Laufwerken kannst du eigentlich fast alle im 4k Format betreiben, außer es steht Samsung drauf ^
 
Das kann man mit nvme-cli machen. Aber warum sollte man das wollen? Erstmal unterstützen das nicht alle NVME-SSDs. Dazu verlierst du alle Daten, die aktuell auf dem Laufwerk sind.
Das ist ja das Problem. Auf dem System, das auf der SSD läuft, kann man das schlecht machen. Deswegen die Frage, ob das erhalten bliebe, wenn man das vor der eigentlichen Installation auf einem Live-System machen würde.
alte Backups die mit 512e erstellt wurden nicht mehr kompatibel sind
Das gilt aber schon nur für Backups auf Blockebene, oder?
Bei den nvme Laufwerken kannst du eigentlich fast alle im 4k Format betreiben, außer es steht Samsung drauf ^
Ich bin bei meiner Suche zu dem Thema über einen Thread gestolpert, bei dem es um eine Kingston-SSD ging, bei der es nicht ging. So oder so, sollte man wohl vorher prüfen, ob das möglich ist.
 
Das ist ja das Problem. Auf dem System, das auf der SSD läuft, kann man das schlecht machen. Deswegen die Frage, ob das erhalten bliebe, wenn man das vor der eigentlichen Installation auf einem Live-System machen würde.

Ja es bleibt erhalten, wenn du die SSD danach "normal" hin oder her formatierst bleibt alles. Kannst du mit den Konsolen befehlen einfach testen.

Die Lösung von Retro-Schrauber funktioniert, du kannst aber auch z.b. AOMEI Partition Assistant Professional unter Windows benutzen - die SSD muss dann natürlich in einem anderen Rechner stecken logischweise ).

Alternativ, so mach ich das jetzt schon 8 Jahre bei Laufwerken für Freunde etc. pp., das MoBo selbst nutzen:

250705204231.png

Das gilt aber schon nur für Backups auf Blockebene, oder?

Da bin ich mir unsicher und will nichts falsches sagen :)

Ich bin bei meiner Suche zu dem Thema über einen Thread gestolpert, bei dem es um eine Kingston-SSD ging, bei der es nicht ging. So oder so, sollte man wohl vorher prüfen, ob das möglich ist.

Auch dazu kann ich nur sagen das es bis jetzt bei jeder WD SNXXXX funktioniert hat. Samsung hatte ich ein paar hier, die wollten das nicht. Zu Kingston habe ich keine persönlichen Erfahrungen.
 
Fakt ist nun mal das ein 4K Format weniger CPU Last, weniger Controller Last ( bei der SSD ), weniger verschwendeten Speicher da weniger ECC Blöcke im Cluster selbst angelegt werden und dazu mehr Durchsatz beim read / write bringt.
Ich glaube du bringst da ein paar Sachen durcheinander. Wir reden ja hier von 512e, also eine emulierte Blockgröße von 512 Byte. Die echte Blockgröße auf der SSD ist da ja schon mindestens 4k oder gar größer. Da ist nichts mit zusätzlichen ECC Blöcken bzw verschwendeten Speicherplatz.
Weiter wird ja sogar in dem von dir verlinkenden Artikel angemerkt, dass das Lesen von 512e Datenträgern keine Leistungseinbusen hat. Und der Artikel bezieht sich sogar nur auf Festplatten, und bei diesen müssen die Sektoren ja noch mechanisch angefahren werden. Wenn es da schon keine Unterschiede gibt, dann erst recht nicht bei SSDs.

Aber ja, beim Schreiben kann es anders aussehen, wenn das Alignment des 512e Blocks auf den echten 4k Block nicht stimmt oder ständig Daten geschrieben werden, die kleiner als 4k sind. Dann muss der Block gelesen, modifiziert und wieder geschrieben werden. Das Alignment machen die ganzen Partionierungs-Tools schon viele Jahre lang richtig. Die erkennen 512e/4kn und sorgen dafür, dass es stimmt. Das gleiche gilt, wenn du dann ein neues Dateisystem auf dem Laufwerk erstellst. Die Standard-Blockgröße von Ext4 ist 4k und und Btrfs sogar 16k. Auch die erkennen 512e Datenträger und kümmern sich darum. Und durch die Blockgröße werden eh nie Daten geschrieben, die kleiner als 4k sind.

Man kann es sicher umstellen, sollte sich aber wirklich keine spürbaren Unterschiede erhoffen. Wobei es gar nicht mal so selbstverständlich ist, dass man die Blockgröße wirklich umstellen kann. Bei Lexar und Crucial geht es zb auch nicht immer. Bei WD hat man noch mit die besten Chancen.
 
Ich glaube du bringst da ein paar Sachen durcheinander. Wir reden ja hier von 512e, also eine emulierte Blockgröße von 512 Byte. Die echte Blockgröße auf der SSD ist da ja schon mindestens 4k oder gar größer. Da ist nichts mit zusätzlichen ECC Blöcken bzw verschwendeten Speicherplatz.

Klär mich auf wenn ich komplett falsch liege aber, so steht das dort ja auch verlinkt:
Wenn die physikalische Größe bei 4kb bzw. 4096byte, oder wie immer wir das nennen wollen, liegt dann kannst du auf diesen Datenträger auch nur mit dieser Größe schreiben. In einem Vorgang müssen also 8 x 512byte geschrieben werden. Zu jedem dieser "512e" Blöcke gehört ein ECC Bereich etc.pp.

Dazu zitiere ich mal:
"Abbildung 4 zeigt das Layout für 512-Byte-Sektoren. Jeder 512-Byte-Sektor verfügt über ein nicht datenbezogenes Overhead von 50 Byte für den ECC-Block und weitere 15 Byte für die Lücke, den Sync/DAM- und den Adressbereich. Dies führt zu einer Effizienz von etwa 88 % (512/(512 + 65)) beim Sektorformat1.

Abbildung 4. altes 512-Byte-Sektor-Layout

Der neue Advanced-Format-Standard bringt den Umstieg auf 4K-Sektoren mit sich, wobei im Prinzip acht herkömmliche 512-Byte-Sektoren in einem einzigen 4K-Sektor zusammengefasst werden (Abbildung 5).

Abbildung 5. Advanced Format: 4K-Sektor-Layout

Der Advanced-Format-Standard verwendet dieselbe Anzahl an Byte für die Lücke, den Sync/DAM- und den Adressbereich, erweitert jedoch den ECC-Block auf 100 Byte. Dies führt zu einer Effizienz von etwa 97 % (4.096/(4.096 + 115)) beim Sektorformat1, was einer Verbesserung von fast 10 % entspricht."


Am Ende bedeutet das doch das du bei 8*512e Blöcken insgesamt 8*50 byte für ECC brauchst sowie 8*15 byte für "5 Byte für die Lücke, den Sync/DAM- und den Adressbereich". Bei einem 4k block brauchst du halt 1*15 byte für den Sync etc. sowie 100 byte für den EEC Bereich.

Wie auch schon im Zitat steht hast du so mehr nutzbaren Platz ( 88 % vs. 97 % ) welcher dir am Ende zur Verfügung steht.

Klär mich auf wenn ich da falsch rechne!

Weiter wird ja sogar in dem von dir verlinkenden Artikel angemerkt, dass das Lesen von 512e Datenträgern keine Leistungseinbusen hat. Und der Artikel bezieht sich sogar nur auf Festplatten, und bei diesen müssen die Sektoren ja noch mechanisch angefahren werden. Wenn es da schon keine Unterschiede gibt, dann erst recht nicht bei SSDs.

Fair und logisch, als ich mich am Anfang mit dem Thema auseinander gesetzt hatte habe ich den ganzen Spaß auf einer externen nvme getestet ( WD SN500 500 GB). Der unterschied beim lesen war bei mir damals 200 mb/s im Peak sowie 20 Sekunden ?!? beim kopieren eines 180 GB random Ordners.

Aber ja, beim Schreiben kann es anders aussehen, wenn das Alignment des 512e Blocks auf den echten 4k Block nicht stimmt oder ständig Daten geschrieben werden, die kleiner als 4k sind. Dann muss der Block gelesen, modifiziert und wieder geschrieben werden. Das Alignment machen die ganzen Partionierungs-Tools schon viele Jahre lang richtig. Die erkennen 512e/4kn und sorgen dafür, dass es stimmt. Das gleiche gilt, wenn du dann ein neues Dateisystem auf dem Laufwerk erstellst. Die Standard-Blockgröße von Ext4 ist 4k und und Btrfs sogar 16k. Auch die erkennen 512e Datenträger und kümmern sich darum. Und durch die Blockgröße werden eh nie Daten geschrieben, die kleiner als 4k sind.

Bei Alignment gehen wir jetzt einfach mal davon aus das es richtig ausgerichtet ist, außer bei einem geklonten Laufwerk habe ich noch nie gesehen das es nicht passen würde. Ich denke auch nicht das es regelmäßig irgendwo passiert das es nicht passt, außer man pfuscht hinterher an den Partitionstabellen rum.

Man kann es sicher umstellen, sollte sich aber wirklich keine spürbaren Unterschiede erhoffen. Wobei es gar nicht mal so selbstverständlich ist, dass man die Blockgröße wirklich umstellen kann. Bei Lexar und Crucial geht es zb auch nicht immer. Bei WD hat man noch mit die besten Chancen.

Wie gesagt ich kann nur sagen das es sich bei mir damals gelohnt hat. Muss im Zweifel wohl jeder selbst für sich Wissen. Lexar hatte ich noch nie selbst in der Hand, Crucial irgendwann 2017 rausgeworfen weil die Software eine Katastrophe ist. Egal ob privat, auf Arbeit oder sonst wo - WD rockt :D Die Wartungssoftware ist einfach angenehm hoch 10.
 
In einem Vorgang müssen also 8 x 512byte geschrieben werden. Zu jedem dieser "512e" Blöcke gehört ein ECC Bereich etc.pp.
Es könnte aber auch sein, dass sich die acht Blöcke einen ECC-Bereich teilen, der einfach immer aktualisiert wird, wenn einer der Blöcke beschrieben wird.

4K-Blöcke könnten auf jeden Fall zu niedrigerer Last für die CPU und den SSD-Controller und auch eventuell zu mehr Speichereffizienz führen und ich werde das mal für die nächste Installation im Hinterkopf behalten, weil verlieren tut man ja sicherlich nichts dadurch, aber es ist jetzt meiner Meinung auch nichts, womit man sich jetzt dringend aufhalten müsste, wenn es darum geht, sich mal mit Linux auseinanderzusetzen, um mal wieder zum Thema zurückzuführen. ;)
 
Klär mich auf wenn ich da falsch rechne!
Du rechnest nicht falsch, nur die Voraussetzungen sind anders.

Als erstes muss ich sagen, dass ich dem Artikel irgendwie keine Grafiken Angezeigt bekomme. Aber nochmal folgendes, bei 512e gibt es auf dem Medium (SSD/HDD) keine 512 Byte Blöcke mehr, diese 512 Byte Blöcke werden dem Betriebssystem einfach vorgegaukelt. Auf dem Speichermedium gibt es nur noch echte 4k Blöcke mit 100 Byte ECC. Das Betriebssystem kennt auch die ECC Daten gar nicht, das ist ein internes System der Datenträger.
Es gibt auch keine 512e Blöcke mit extra ECC. Das würde ja auch keinen Sinn ergeben, warum sollte man etwas emulieren, was genau so auf dem Medium ist?
Und da es bei 512e ja nur echte 4k Blöcke gibt, ist das auch das "Problem" von 512e. Der 4k Block inklusive ECC kann ja nur im ganzen geschrieben werden.

Aber Deine Rechnung stimmt, wenn man echte 512 Byte Blöcke mit 4k Blöcken vergleicht.

 
  • /boot/efi (vfat): Mountpunkt für die EFI-Systempartition, Bootloader
  • swap (32 GB): Auslagerungsdatei.
  • Linux Mint (100 GB, ext4): Ruhig und sicher.
  • CachyOS (100 GB, Btrfs): FPS, Deutschsprachige Wiki.
  • Nobara (100 GB, Btrfs): Einsteigerfreundlichkeit.
  • Bazzite (100 GB, Btrfs): FPS, Rollback.
  • Spiele (3,6 TB, ext4): Stabilität, Kompatibilität mit allen OS.
Halte ich für den Anfang für ziemlich umfangreich. Ja, kann man machen, ist bestimmt auch ein spannendes Projekt, nur, so als Start würde ich mir echt erst einmal nur die Live-Systeme anschauen, dann entscheiden, was mich daran wie anspricht oder abstößt. Eher KDE oder doch eher GNOME oder was ganz anderes?

Ob nun Cachy, Nobara oder Bazzite im Hintergrund läuft, ist für den Anfänger eh nur Makulatur. Ich würde da eher auf so Sachen wie einen vernünftigen Paketmanager achten. Auch wenn man irgendwann lernt, mit der Konsole schneller zum Ziel zu kommen, ist es für den Umsteiger umso wichtiger, die elementaren Dinge mit Klicki-Klicki simpel zu erreichen. Dazu zählt im ersten Moment die Installation neuer Software als auch ihr Update und ein Kontrollzentrum, mit dem ich das System nach eigenen Bedürfnissen anpassen kann.

100 GB für die Systempartitionen ist schon ok. Könnten vielleicht noch 20 GB weniger sein. Mein Manjaro habe ich inzwischen seit Jahren im Einsatz, so ziemlich jeden Desktop installier und 'ne Tonne Programme darauf. So sieht der Platzbedarf bei mit aus

1751752392305.png


Wichtiger Tipp:
Lege das /home wie bei mir auf eine eigene Partition. Mache sie groß genug, besonders wenn du mehre Distris nutzen willst, damit deine persönlichen Daten darin Platz finden. Hinsichtlich der Distros auch da immer die gleiche Partition als /home mounten und dann nur den Usernamen etwas variieren, dann ist auch da eine Trennung drin.

Mein Home-Verzeichnis habe ich jetzt schon seit einer gefühlten Ewigkeit am Laufen. Habe das sogar nacheinander zwischen unterschiedlichen Distributionen genutzt, was so gut wie nie Probleme machte. Vergleiche es damit, dass man Daten und System in Windows auch trennen sollte.

Ich habe eine 2 TB SSD für Games. Die habe ich in mein Home-Verzeichnis gemountet.

1751752565413.png


Das hat den Vorteil, dass diese Partition als Ordner in deinem persönlichen Ordner und nicht als Laufwerk im jeweiligen Filebrowser auftaucht. Es kann nämlich sein, dass du in bestimmten Situationen mit den Filebrowsern unterschiedlichen Desktop Environments konfrontiert wirst und die Laufwerke, die keinen festen Mountpoint haben und nur dynamisch durch Anklicken gemountet werden, im File-Dialog nicht angezeigt werden.

Ach so, noch so eine Erfahrung:
Erst Windows installieren und dabei gleich die wichtigsten dafür zu nutzenden Partitionen erstellen und gleich formatieren. Nach der Installation dann mit einem Live-Linux via Gparted oder dem KDE Partionierungswerkzeug die von Windows angelegten Partitionen etwas verschieben, um der EFI-Partition etwas mehr Platz zu schaffen. Windows ist mit 200 MB manchmal zu geizig. Platz ist heute ja kein Ding mehr, also kann man auch gleich 1024 MB oder überschwängliche 2048 MB dafür bereitstellen.

Und jetzt der wirklich allerletzte Hinweis: ;)
Windows kennt nur sich und wird kein Bootmenü für was anderes aka Linux erstellen. Linux ist anders. Aber auch da gilt die Devise, dass der Letzte bei der Installation dem Menü seinen Stempel aufdrückt. Soll heißen, schaue dir an, welches Bootmenü dir von welcher Distri am besten gefällt und installiere diese als Letzte. Man kann Grub auch nachträglich mit einem Theme versehen, aber am Anfang muss man nicht alles sofort machen. Da kommt es schon geiler, wenn das Bootmenü etwas hermacht und nicht nur aus einem schwarzen Bildschirm mit weißer Schrift besteht.

Ok, noch ein alllerallerallerletzter Hinweis: :D
Gewöhne dich schon mal dran, dass ein UEFI-Update deines Boards dazu führt, dass die Linux-Bootloader nicht mehr erkannt werden. Bei Manjaro ist das kein Problem. Einfach Live-Version starten, im Bootmenu Detect EFI-Bootloader auswählen, ins System kommen und dann Grub kurz aktualisieren. Ich weiß aber nicht, wie das bei den anderen Distris läuft. Also sei gewappnet!

Nu ist aber Schluss. Ehrlich!
 
Zuletzt bearbeitet:
Getrenntes / und /home (so wie @Tekkla sagt), halte ich für eine absolut wichtige Empfehlung, gerade auch für Neulinge.

Gleich richtig machen. Nicht fragen, einfach machen!

Ich würde auch noch gleich eine boot und Swap anlegen. Aber / (sprich root) und /home sind das Minimum.
Gewöhnt euch gar nicht erst an, alles auf eine Partition zu klatschen.

Nicht fragen, machen.
 
Ich würde auch noch gleich eine boot und Swap anlegen. Aber / (sprich root) und /home sind das Minimum.
Gut, um eine Boot-Partition kommt man bei UEFI-Systemen doch normalerweise gar nicht herum, oder? Beim Swap könnte man für Swap-Files statt einer Swap-Partition argumentieren, weil man damit deutlich flexibler ist. Ich nutze schon seit Ewigkeiten keinen Swap mehr, könnte aber jederzeit einen anlegen. Ich weiß nur nicht, ob es dafür eine grafische Möglichkeit gibt.
 
Ich würde auch noch gleich eine boot und Swap anlegen. Aber / (sprich root) und /home sind das Minimum.
Gewöhnt euch gar nicht erst an, alles auf eine Partition zu klatschen.

Nicht fragen, machen.
Um den Hintergrund von swap zu klären: es ist eine Auslagerungsdatei, die bei heutigen Systemen kaum noch Anwendung findet, weil die Arbeitsspeicher zumeist groß genug sind, oder? Wie auch bei Windows ist swap langsamer als der RAM, weil die SSD langsamer als der RAM ist.
Kann ich darauf (mit 32 GB RAM) nicht einfach verzichten? Oder wäre es dennoch besser, swap mit wenigstens 32 GB einzurichten? Man kann wohl die swapiness auf einen Wert von 0 bis 100 einstellen, um zu steuern, wie zurückhaltend bzw. intensiv swap genutzt wird. Wenn ich swapiness auf 0 setze, würde swap nur genau dann genutzt, wenn der RAM nicht reicht und überläuft. Stimmt das so?
 
Habe 4096 MB als Swap File bei 32 GB RAM. Muss gestehen, ich habe die Auslastung nie kontrolliert. Ich vermute,,in der Theorie kann man sich die sparen. In der Praxis? Jammert das OS dann?
 
Um den Hintergrund von swap zu klären: es ist eine Auslagerungsdatei, die bei heutigen Systemen kaum noch Anwendung findet, weil die Arbeitsspeicher zumeist groß genug sind, oder? Wie auch bei Windows ist swap langsamer als der RAM, weil die SSD langsamer als der RAM ist.
Kann ich darauf (mit 32 GB RAM) nicht einfach verzichten? Oder wäre es dennoch besser, swap mit wenigstens 32 GB einzurichten? Man kann wohl die swapiness auf einen Wert von 0 bis 100 einstellen, um zu steuern, wie zurückhaltend bzw. intensiv swap genutzt wird. Wenn ich swapiness auf 0 setze, würde swap nur genau dann genutzt, wenn der RAM nicht reicht und überläuft. Stimmt das so?
Also ich hab schon seit Jahren keine swap-Partition oder swap-File mehr und keine Probleme damit. Selbst mit 16GB bin ich da in keine Probleme gelaufen, allerdings hab ich da auch noch auf Windows gezockt.
 
Zuletzt bearbeitet:
Zurück