Linux Advanced Format - LBAs & Sector Size: 512 vs 4096

[Ambrosius]

Streng genommen kein linuxspezifisches Thema, außerdem auch eig ein alter Hut, aber dennoch interessant.

Spätestens mit dem Einzug von NVMe SSDs in fast alle PC-Klassen (mobile, desktop, handheld, etc pp) stellt sich die Frage wieder in den Vordergrund, warum eig 512 Bytes immer noch die Standard Sektorgröße ist. Da flashbasierte Speicher keine physikalischen Sekoren per se haben, da ja eigentlich nur Bitzellen, ist es kaum verwunderlich, dass mit immer mehr Kapazität auch die (logische) Sektorgröße angehoben werden soll.
Vorteil: performanter & effizienter, mehr Features können implementiert werden, auch Sicherheitsrelevante Features
Nachteil: n/a ?

Rene geht in seinem Video mit herrlich deutsch-englischem Akzent darauf ein, wie man das fix überprüfen kann

#smartctl-a /dev/nvme0n1

Unter dem Punkt supported LBA Sizes steht bei mir:
WD

Id Fmt Data Metadt Rel_Perf
0 + 512 0 2
1 - 4096 0 1

Bei ner anderen Nvme, wiederum
SK Hynix

Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
1 - 4096 0 0

Ferner auch mit:

#nvme id-ns -H /dev/nvme0n1

WD

[...]
LBA Format 0: Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good (in use)
LBA Format 1: Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0x1 Better

vs andere NVme (SK Hynix):

[...]
LBA Format 0: Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)
LBA Format 1: Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best

Das Re-formatieren von 512 auf 4096 ist bei den meisten SSDs möglich, aber es geschieht low-level, also noch unter dem File System Layer. Daten gehen sofort verloren, also nur auf leerer SSD machen oder vor einer Neu-Installation.

Das ist aber schnell gemacht und kein soo großer Akt. Mich würde vielmehr interessieren, wie man die herstellereigenen Angaben zum erwarteten Performancegewinn (good, better, best) bewerten soll. Sind das genormte Werte? Und wie kann 512 und 4096 beide gleich gut sein?

Auch ein nicht unwichtiger Aspekt ist Overhead durch andere beteiligte Prozesse wie z.b. Wear Leveling und auf höheren Layern Checksumming, LVM etc, der durch die richtige Wahl der logischen Sektorengröße weiter minimiert werden kann.

Wie sind eure Erfahrungen, hat jemand vielleicht 4096 am laufen und kann berichten?


Edit meinte gerade noch:
SSD Hersteller oben hinzugefügt
und schnell mal woanders gegencheckt: es stimmt, Samsung SSDs bieten kein 4kn (4096) an, und SK Hynix geben bei beiden Sektorgrößen stets Best an (0 perf)


Lektüre:

Advanced Format - Wikipedia

en.wikipedia.org

Advanced Format - ArchWiki

You DO NOT use your NVMe SSDs to their BEST PERFORMANCE: THIS is the SIMPLE FIX!
→

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

 

[linrunner]

Das ist aber schnell gemacht und kein soo großer Akt

Magst Du mal die Kommandos dazu posten? Werden ja wahrscheinlich in dem Video gezeigt.

 

[hikaru]

Spätestens mit dem Einzug von NVMe SSDs in fast alle PC-Klassen (mobile, desktop, handheld, etc pp) stellt sich die Frage wieder in den Vordergrund, warum eig 512 Bytes immer noch die Standard Sektorgröße ist.

Das hat wohl historische Gründe. Aber selbst bei HDDs hat sich vor ca. 15 Jahren 4kB als physische Sektorgröße durchgesetzt. Daher rührte das ganze Alignment-Hick-Hack, das bis vor ein paar Jahren öfter mal aufploppte, bis sämtliche Software ihr Standardverhalten auf 4kB-Blöcke umgestellt hatte.

Da flashbasierte Speicher keine physikalischen Sekoren per se haben, da ja eigentlich nur Bitzellen, ist es kaum verwunderlich, dass mit immer mehr Kapazität auch die (logische) Sektorgröße angehoben werden soll.

Flashspeicher haben aber Flashzellen, und deren Größe hat eine ähnliche Bedeutung wie die Sektorengröße bei HDDs:
Bleibst du logisch unterhalb der Zellengröße, dann bekommst du massive Performanceeinbußen, weil auf Zellen unnötig mehrfach zugegriffen werden muss. Überschreitet du sie, verschwendst du Speicherplatz und bekommst beim Umgang mit kleinen Datenmengen ebenfalls (kleine) Performanceeinbußen, weil du auch auf Zellen zugreifst, auf die du eigentlich nicht zugreifen müsstest.
Es lässt sich also nicht pauschal sagen, dass größere logische Sektorgrößen vorteilhaft wären. Ideal wäre es, die physische Zellengröße deiner SSD exakt zu kennen, und daran deine Software auszurichten. Allerdings gibt es auch hier Randfälle, in denen ein 1:1-Mapping nicht ideal ist.

Und wie kann 512 und 4096 beide gleich gut sein?

512B ist ein ganzzahliger Teiler von 4kB.
Unter der Annahme, dass deine Dateien Vielfache von 4kB als Größe haben, spielt es tatsächlich keine Rolle, ob du einen Datenträger der physisch mit 512B arbeitet, logisch mit 512B oder 4kB ansprichst.
Natürlich ist die tatsächliche Größe der meisten Dateien kein Vielfaches von 4kB, aber angesichts heutiger Dateigrößen ist der Verschnitt relativ klein und kann daher meist vernachlässigt werden. Tatsächlich relevant ist es eigentlich nur, wenn du auf einem Datenträger hauptsächlich kleine Plaintext-Dateien (<4kB) ablegst.

 

[Ambrosius]

Magst Du mal die Kommandos dazu posten? Werden ja wahrscheinlich in dem Video gezeigt.

nvme format --lbaf=1 /dev/nvme0n1
wie im hier im Arch Wiki referenziert

Allerdings gibt es auch hier Randfälle, in denen ein 1:1-Mapping nicht ideal ist.

Tatsächlich? Ich dachte das wäre die ideale Ratio.

 

[hikaru]

Tatsächlich? Ich dachte das wäre die ideale Ratio.

Ist sie im Normalfall auch. Aber angenommen, du schreibst ausschließlich Dateien, deren Größe weit oberhalb der Zellengröße liegt, und das mit einem Hostcontroller der sehr wenig Rechenleistung hat, dann kann es vorteilhaft sein, eine größere logische Blockgröße zu wählen.
Wie gesagt: Randfälle.

 

[Ambrosius]

Leuchtet ein. Es gibt einen Talk in YT wo speziell QLC Speicher am meisten von größeren nativen Sektoren profitieren

@hikaru nutzt du bei mechanischen Festplatten (HDDs) 4k-byte Sektoren?
Über den Nutzen bei NVMes lässt sich ja gut und gerne streiten, aber 7 - 11% ige Performancesteigerungen bei HDDs, das ist fast schon verschwenderisch.

Format efficiency gains resulting from the 4K sector structure range from 7 to 11 percent in physical platter space.
<a href="https://en.wikipedia.org/wiki/Advanced_Format#cite_note-9"><span>[</span>9<span>]</span></a>

Beitrag automatisch zusammengeführt: 29 Jan. 2026

Hier auch mal der Faden im TechPowerUp Forum

Setting 4k sector size on NVMe SSDs: does performance actually change?

NVMe specifications allow the host to send specific low-level commands to the SSD in order to permanently format the drive to 4096 bytes logical sector size (it is possible to go back to a 512...

www.techpowerup.com

 

[hikaru]

@hikaru nutzt du bei mechanischen Festplatten (HDDs) 4k-byte Sektoren?

Ja. Und ich würde vermuten, die allermeisten anderen User tun das auch (oft, ohne es zu wissen), denn praktisch alle relevanten Tools zum erstellen von Partitionen (Gparted, Linux-Installer) wurden vor geschätzt 10 Jahren auf 4kB-Sektoren umgestellt.

Über den Nutzen bei NVMes lässt sich ja gut und gerne streiten, aber 7 - 11% ige Performancesteigerungen bei HDDs, das ist fast schon verschwenderisch.

Das kann sogar noch viel mehr werden. Bei einem falschen 512B-Alignment auf einem 4kB-Datenträger sind theoretisch Einbußen von Faktor 8 (also 800%) möglich.

 

[cuco]

Wo möglich, setze ich in meinem Heimserver auf 4K statt 0,5K Blöcke. Notiert habe ich mir "damals"

apt install nvme-cli
nvme id-ns /dev/nvmeXn1 #-> ein Format mit 0 Medatata (ms:0) und 4kB Sektoren (lbads:12) wählen
nvme format /dev/nvmeXn1 -l 3 #->Beispiel für die Optane-SSD, nur einmalig nötig, die verbaute Samsung SSD kann leider nur ms:0 mit lbads:9 (512 Byte Sektoren)

Soll heißen: Meine Intel Optane SSD konnte ich auf ein 4K-Format umformatieren, meine Samsung-SSD (Evo 970 Plus) nicht.
Meine HDDs haben auch 4K-native Blöcke. Bin mir aber nicht mehr sicher, ob ich die mit einem Seagte-Tool darauf umstellen musste, oder ob ich die schon so gekauft habe.

Erfahrungen (unter Proxmox/Debian): Problemlos. Läuft halt. Mehr gibt's da nicht zu sagen.

 

[thickpad]

Das Re-formatieren von 512 auf 4096 ist bei den meisten SSDs möglich, aber es geschieht low-level, also noch unter dem File System Layer. Daten gehen sofort verloren, also nur auf leerer SSD machen oder vor einer Neu-Installation.

So wirklich weiß man vorher nie ob es geht, bei meinen geliebten SK Hynix P31 Gold geht es bzw. nicht, bei einem kürzlich erworbenen X1 Carbon Gen9 wo der Vorbesitzer eine Crucial T500 verbaut hat wiederrum schon aber was man da merkt ist vielleicht messbar aber nicht fühlbar wie z.B. damals der Wechsel von drehenden Scheiben auf die erste SATA SSD oder später der Wechsel von SATA SSD auf eine NVME und der Vergleich wenn man da mal ein 1TB Daten kopiert...

❯ sudo smartctl -i /dev/nvme0n1
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-6.18.8-2-cachyos] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       CT1000T500SSD8
Serial Number:                   
Firmware Version:                   P8CR004
PCI Vendor/Subsystem ID:            0xc0a9
IEEE OUI Identifier:                0x00a075
Total NVM Capacity:                 1.000.204.886.016 [1,00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      0
NVMe Version:                       2.0
Number of Namespaces:               1
Namespace 1 Size/Capacity:          1.000.204.886.016 [1,00 TB]
Namespace 1 Formatted LBA Size:     4096
Namespace 1 IEEE EUI-64:            00a075 014ead85e6
Local Time is:                      Sat Feb  7 13:00:46 2026 CET


Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 -     512       0         1
 1 +    4096       0         0

 

[Ambrosius]

Wenn man sich tatsächlich dazu entschließen würde die Sektorgröße von 512B auf 4096B anzuheben, wie verhält sich z.b. mkfs wenn man ne Partition anschließend formatiert?
In der Manpage steht dazu:

-b block-size

Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined bythe filesystem size and the expected usage of the filesystem (see the -T option). If block-size is negative, then mke2fs will useheuristics to determine the appropriate block size, with the constraint that the block size will be at least block-size bytes. This is useful forcertain hardware devices which require that the blocksize be a multiple of 2k.

Unter Heuristik verstehe ich in diesem Fall ein gewisses Detektionsvermögen von mkfs, vernünftige Werte auszuwählen und im Bedarfsfall von den defaults abzuweichen.
Aber die Standardwerte bei ext4 z.b. für einen Block sind schon 4k. Das ergäbe ein sauberes 1:1 Mapping so wie @hikaru erwähnt hat. Ob das nun erwünscht ist oder nicht, ist die Frage

Meine HDDs haben auch 4K-native Blöcke.

Blöcke oder Sektoren?

Code:
#nvme id-ns -H /dev/nvme0n1

@thickpad Welche Ausgabe kommt bei dir beim obigen Befehl mit der P31?

 

[thickpad]

Weiß ich noch auswendig die hat nur das 0 Profil mit 512kb nicht das 1 mit 4096kb. Das wird ausgegeben aber funktioniert nicht. Somit kein Switch möglich. Aktuell beobachte ich das auch bei anderen sk hynix.

 

[Ambrosius]

Da verwechselst du das aber mit dem Befehl

Code:
#smartctl-a /dev/nvme0n1

Mit

# nvme id-ns -H /device

siehst du ganz unten unter LBA Format dann beide Bewertungen (good, better, best)

Bei Samsung SSDs wirst du hier fast immer nur dein Eintrag bzgl 512B sehen

 

[thickpad]

@Ambrosius

Glaube das meinte ich, kann aber gern nochmal gucken wenn relevant? Die Ausgaben von den beiden Tools waren weitestgehend redundant.

Bei den ganzen kleinen OEM-NVMes von Thinkpads ging das bei mir noch nie umzustellen. Sonst hab ich halt aus guten alten Zeiten in allen Geräten weil das damals das beste kaufbare Stück Flash-Speicher in Sachen Wärmeentwicklung und Energieffizienz von den SK Hynix P31 Gold größere Mengen.

Die können das auch nicht.

Die einzige NVME von mir die beide Modi kann war die Crucial T500 in dem kürzlich erworbenen X1 Carbon Gen9 hier im Forum.

Die P31 Gold gibt das lbaf 1 schon aus aber man kann da nicht hin wechseln. S.u. alles versucht.

Hatte da 2 Stunden investiert dann beschlossen das es komplet Sinnfrei ist für evtl. messbare aber nicht fühlbare Unterschiede. Erst dank dem Thread hier kam ich auf die Idee das bei der Crucial T500 zu versuchen die es eben kann.






tl,dr. Praktisch völlig irrelevant für Laptops nach meinem Gefühl. Evtl. macht das irgendwo in Hochleistungssystemen Sinn die ständig Terabyteweise Daten kopieren irgendwelche großen Videodateien transkodieren oder völlig anders agieren.

Ich merk auch nicht im Betrieb ohne Messung ob ich an ner Gen3, Gen4 oder Gen5 NVMe sitze oder ob die DRAMless ist oder nicht wenn ich ned auf Datenraten und Specs schauen kann beim kopieren und ggfls. hohen Füllstand habe.

Von der sog. Schwuppidizität (hier im Forum gelernt den Begriff und dann erst erfahren das die c´t das geprägt hatte) merk ich seit dem Umstieg von drehenden Platten auf Festspeicher nix mehr.


Ein paar alte Studien von Seagate hab ich gefunden aber so wirklich fundiert war das alles nischt. https://www.seagate.com/de/de/blog/advanced-format-4k-sector-hard-drives-master-ti/

 

[cuco]

Blöcke oder Sektoren?

Sektoren. Also "4Kn"

Bei Samsung SSDs wirst du hier fast immer nur dein Eintrag bzgl 512B sehen

Ja. Hier z.B. die Ausgabe für eine Samsung 970 Evo Plus 2TB:

LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)

Und hier für eine Intel Optane P4801X 100GB:

LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good
LBA Format 1 : Metadata Size: 8 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good
LBA Format 2 : Metadata Size: 16 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good
LBA Format 3 : Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best (in use)
LBA Format 4 : Metadata Size: 8 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best
LBA Format 5 : Metadata Size: 64 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best
LBA Format 6 : Metadata Size: 128 bytes - Data Size: 4096 bytes - Relative Performance: 0 Best

Und für die HDDs (Seagate Exos X16 16TB) sieht's so aus:

./SeaChest_Format_152_12130_64 -i -d /dev/sda

Logical Sector Size (B): 4096
Physical Sector Size (B): 4096

Zum Vergleich der Output auf einer Samsung 870 QVO:

Logical Sector Size (B): 512
Physical Sector Size (B): 512