Speichergeräte-Ausrichtung - Berechnen Sie die Ausrichtung nachfolgender Partitionen eines optimal ausgerichteten 32-MB-Speichers

1487
user212827

Zusammenfassung

Ich versuche zu verstehen, wie man die Ausrichtung nachfolgender Partitionen eines optimal ausgerichteten 32MiB( 65535Sektors) eher als gewöhnlich berechnet 1MiB( 2048 sector).

Hintergrund

Ich habe vor kurzem ein gekauft SAMSUNG SSD 850 EVO (M.2 1TB),

# cat /sys/block/sdx/queue/optimal_io_size > 33553920 # cat /sys/block/sdx/queue/minimum_io_size > 512 # cat /sys/block/sdx/alignment_offset > 0 # cat /sys/block/sdx/queue/physical_block_size > 512 # cat /sys/block/sdx/queue/logical_block_size > 512 # cat /sys/block/sdx/queue/hw_sector_size > 512  # fdisk -l > Disk /dev/sdx: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 33553920 bytes > Disklabel type: gpt 

Die Berechnung des ersten Sektors ist nicht schwierig.

Erlaube GNU parted, die Ausrichtung automatisch zu berechnen

(parted) mkpart primary 0% 100% 

Das Ergebnis ist eine Ausrichtung, die bei Sektor 65535( 32MiB) beginnt .

Berechnen Sie die Ausrichtung manuell

(optimal_io_size + alignment_offset) / physical_block_size 

Die Verwendung der Daten für SAMSUNG SSD 850 EVO (M.2 1TB)und die Anwendung der Formel führt zu

(33553920 + 0) / 512 = 65 535 

das Problem

Normalerweise fügte ich beim Erstellen einer Partition einfach offset + lengthdie vorherige Partition als Start für die nächste Partition hinzu, z.

(parted) mkpart primary 1MiB 2MiB (parted) mkpart primary 2MiB 514MiB (parted) mkpart primary 514MiB 1538MiB ... 

Versuch zu etwas Ähnlichem für SAMSUNG SSD 850 EVO (M.2 1TB)

(parted) mkpart primary 65535s 67582s # OK ~32MiB 33MiB (parted) mkpart primary 67583s 100% or (parted) mkpart primary 33MiB 100% 

führt zu folgender Warnung:

Warning: The resulting partition is not properly aligned for best performance. Ignore/Cancel? 

Abhilfe

Das Laufwerk ist ziemlich wählerisch und mein bester Versuch war, die exakten Sektoren zu berechnen. Leider hat dies zu komplizierten Berechnungen geführt, bei denen ich nicht erklären kann, warum die Partitionen optimal ausgerichtet wurden ( align-check optimal <partition number>).

(parted) unit s (parted) print free Number Start End Size File system Name Flags 34s 65534s 65501s Free Space 1 65535s 67582s 2048s 67583s 131069s 63487s Free Space 2 131070s 1179645s 1048576s 1179646s 1245164s 65519s Free Space 3 1245165s 9633772s 8388608s 9633773s 9699179s 65407s Free Space 4 9699180s 1953467279s 1943768100s 1953467280s 1953525134s 57855s Free Space 

Soweit ich 65535das beurteilen kann, muss jeder Sektor in einem Abstand beginnen, der ~ 32MiB (oder 65535+1 = 32MiB) entspricht. Ich gehe davon aus, dass der Byte-Versatz ist 0und nicht 1. Gegeben 1MiB = 2048s.

Die erste Partitionsgröße soll 1MiBalso der Stop sein 65535 + 2048 - 1 = 67582.

(parted) mkpart primary 65535s 67582s 

Wenn die vorherige Partition unter 32MiBder nächsten liegt, beginnt die nächste Partition einfach mit previous partition offset + 32MiB. Bei der Partition 2im obigen Beispiel beginnt sie mit ~64MiB( 65535s * 2 = 131070s). Die Größe soll 512MiB( 512 * 2048 = 1048576) sein, daher ist der Stop 131070 + 1048576 - 1 = 1179645.

(parted) mkpart primary 131070s 1179645s 

So weit so gut, aber was wäre der optimale Start für die Partition 3? Welcher Offset ist das erste verfügbare 32MiB-Intervall?

1179645 / 65535 ~= 18,000223 

Derzeit mit 18 Intervallen und überlappend auf 19. Die nächste Partition sollte daher am 19. Intervall beginnen?

19 * 65535 = 1245165 

Die Größe soll 4096MiB( 4096 * 2048 = 8388608) sein, daher ist der Stop 1245165 + 8388608 - 1 = 9633772.

(parted) mkpart primary 1245165s 9633772 

Für die nächste Partition also

9633772 / 65535 ~= 147,0019 148 * 65535 = 9699180 

Und so weiter und so fort.

Ich habe bisher noch keine Diskussion darüber gefunden, und ich habe das Gefühl, die Partitionierung zu kompliziert zu machen.

1
Etwas stimmt nicht, ich kann nicht darauf vertrauen, dass die optimale Größe nicht eine Potenz von 2 (65535) ist, während 65536 eine Potenz von 2 ist. Ich bin fast sicher, dass dies ein Fehler ist. Ich sehe, Sie verwenden GPT, aber fdisk scheint zumindest Probleme mit der DOS-Partition zu haben (https://unix.stackexchange.com/a/303358/130000). pim vor 6 Jahren 0
Nach Ihrem [@pim] -Hinweis habe ich auch https://superuser.com/questions/352572/why-does-the-partition-start-on-sector-2048-in- statt-von-63 gefunden, auf die [The gen auf Disk-Partitionsausrichtung.] (http://jdebp.eu./FGA/disc-partition-alignment.html), das [Rod Smiths Gdisk] (http://rodsbooks.com./gdisk/) empfiehlt. Die Verwendung von "gdisk verify disk" führt zu "Achtung: Partition [1-4] beginnt nicht an einer Grenze von 8 Sektoren." Dies kann bei einigen modernen (2009 und später) Festplatten zu einer beeinträchtigten Leistung führen. " user212827 vor 6 Jahren 0

2 Antworten auf die Frage

0
user212827

Mit GPT fdisk Tutorial gdisk berechnete es automatisch die Ausrichtung nachfolgender Partitionen, wenn +beispielsweise

Last sector (8390656-15634398, default = 15634398) or {+-}size: +2G 

erstellt 2GiB (Gibibyte) aus dem zuletzt bereitgestellten Sektor.

Die Partitionen sind auf ausgerichtet 2048s. GNU parted bestätigt, dass die Partitionen align-check minimalaber nicht sind align-check optimal.

Die blockdev --getalignoff /dev/sdxkehrt zurück 0.

0
Johnny The Critic

Einige sagen, es sei wichtig, SSDs entlang der ERASE BLOCK- und NAND-PAGE-GRÖSSEN auszurichten.

evo 840 hat anscheinend ungewöhnliche Erase-Block- und Nand-Parameter: 1536kb und 8k Ich bin mir nicht sicher, welche der 850 ist (samsung möchte diese Informationen nicht veröffentlichen (Geschäftsgeheimnis)) ...

Ich habe einen universellen Ausrichtungswert entwickelt, der alle bekannten SSDs sowie deren Löschblock- und NAND-Seitengrößen abdeckt. Ich empfehle die Verwendung eines Offsets von 6291456 Bytes (Sektor 12288 (6144kb = 6mb) oder ein beliebiges Vielfaches (12mb, 18mb, 24mb usw.). Dieser Offset sollte mit jeder bekannten SSD (oder hdd für diese Angelegenheit) funktionieren. Abhängig vom NAND SEITENGRÖSSE, mit der Sie sich befassen Ich würde empfehlen, Ihre ALLOCATION UNIT SIZE möglichst während des Formats mit der NAND-SEITENGRÖSSE abzustimmen, um READ MODIFY WRITE-Probleme zu vermeiden, jedoch sollte 4k bei fast jedem SSD-Wert auch einen akzeptablen Wert darstellen, selbst wenn Ihr Laufwerk dies erfordert ist intern übermäßig ausgestattet Ich würde immer noch 10% der Festplatte unformatiert lassen, um WRITE AMPLIFICATION-Probleme zu vermeiden (ich lasse 17% OP). Ich empfehle Ihnen außerdem, wenn Sie Ihre Parameter mit Sicherheit festgelegt haben, das QUICK FORMAT NICHT zu verwenden " Wenn Sie diese Option wählen, nehmen Sie das normale Format vor. Für eine SSD dauert es nicht lange. Lassen Sie mich wissen, ob dies Ihnen hilft oder nicht, und fügen Sie ggf. Ihre Ideen hinzu.

PS finde ich teilweise umständlich zu benutzen und bevorzuge gdisk. In gdisk können Sie unter "x" im xpert-Menü "den Wert für die Sektorausrichtung einstellen" einstellen. Wenn Sie dies tun, werden alle erstellten Partitionen automatisch so berechnet, dass sie beim nächsten Vielfachen dieses Werts beginnen. Dies führt dazu, dass alle Partitionen ordnungsgemäß ausgerichtet werden, vorausgesetzt, der angegebene Wert ist korrekt.