Corretto allineamento delle partizioni su un HDD di formato avanzato mediante Parted

Per prima cosa creo una partizione correttamente allineata in una nuova tabella GPT usando parted specificando le percentuali per l'inizio e la fine della partizione:

# parted -a optimal /dev/sdb
GNU Parted 2.3
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mktable gpt
Warning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Y
(parted) mkpart primary 0% 1%
(parted) p
Model: ATA WDC WD30EZRX-00M (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  2097kB  1049kB               primary

(parted) quit

Si noti che questo disco utilizza il formato avanzato, ma riporta correttamente la dimensione del settore fisico 4096Ba Parted. Vediamolo di nuovo, usando i settori come unità:

# parted -a optimal /dev/sdb
GNU Parted 2.3
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) p
Model: ATA WDC WD30EZRX-00M (scsi)
Disk /dev/sdb: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End    Size   File system  Name     Flags
 1      2048s  4095s  2048s               primary

(parted) quit

• Perché ha avviato la partizione in 2048se non 34squal è il primo settore possibile ?
• 34snon è un settore iniziale correttamente allineato se la dimensione del settore fisico è 4096Be la dimensione del settore logico (che è quello specificato in Parted) è 512B. Un settore iniziale correttamente allineato è divisibile per 8(poiché dimensione del settore fisico / dimensione del settore logico = 8). Ciò significa che 40sè il primo settore iniziale correttamente allineato, ma non viene utilizzato. Perché?

Se proviamo a creare una partizione di 100MiBcapacità correttamente allineata a partire da 40suna nuova tabella delle partizioni GPT:

# parted -a optimal /dev/sdb
GNU Parted 2.3
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
Warning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Y
(parted) mkpart primary 40s 204839s
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? I
(parted) unit MiB
(parted) p
Model: ATA WDC WD30EZRX-00M (scsi)
Disk /dev/sdb: 2861588MiB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start    End     Size    File system  Name     Flags
 1      0.02MiB  100MiB  100MiB  fat32        primary

(parted)
(parted) unit s
(parted) p
Model: ATA WDC WD30EZRX-00M (scsi)
Disk /dev/sdb: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End      Size     File system  Name     Flags
 1      40s    204839s  204800s  fat32        primary

(parted)

• Riceviamo ancora l' Warning: The resulting partition is not properly aligned for best performance.avviso, anche se 40se 204840 ( 204839s+ 1) sono entrambi divisibili per 8. Perché?

La separazione è solo eccessivamente conservatrice. La pratica comune in questi giorni è quella di allineare le partizioni sui confini di 1MiB (settore 2048) perché funziona su dischi di formato avanzato, su alcuni tipi di configurazioni RAID che richiedono l'allineamento e sulla maggior parte degli SSD. Per un disco di formato avanzato, fintanto che l'allineamento è su un multiplo di 8, stai bene, e 2048 è un multiplo di 8. Lo spazio su disco perso è incostante - 0,0000336% dello spazio su disco totale, se l'ho fatto la matematica è giusta e non ho sbagliato a scrivere nulla. Quindi non preoccuparti; basta usare l'allineamento 1MiB.

Probabilmente aggiungerò che su Linux si può verificare una situazione in cui partednon si può mai passare contemporaneamente un controllo di allineamento ottimale e minimo .

La ragione di ciò è che parted(almeno dalla versione 3.2) si affida libblkid, che a sua volta riporta valori da /sys/block/<disk>/queue/minimum_io_sizee /sys/block/<disk>/queue/optimal_io_size(vedi io-limits.txt ).

Quindi, mentre per un disco di formato avanzato il primo è probabilmente simile a 4k, il secondo può avere un valore folle, ad es 65535 * 512 == 33553920.

Ora se osserviamo il codice sorgente - l'allineamento "corretto" o "migliore prestazione" è definito dalla formula in parted.c :: partition_align_check () :

part->geom.start % pa->grain_size == pa->offset, 

dove grain_sizeproviene dalla dimensione del blocco I / O sopra, geom.startè il nostro offset di partizione e l'offset di allineamento pa->offsetè abbastanza spesso zero.

Per impostazione predefinita, parted presuppone che 1 MiB sia ottimale e ~ 4k sia la dimensione del blocco minima (non del tutto, è un po 'di semplificazione), quindi questi valori sarebbero correlati; tuttavia, se libblkiddecide diversamente,parted tende a fidarsi di esso e sostituisce quel valore predefinito di 1 MiB con il valore trovato in /sys/block/<disk>/queue/optimal_io_size. (Allo stesso tempo, /sys/block/<disk>/queue/minimum_io_sizemolto probabilmente ti darà lo stesso 4096 B.)

In tal caso, il controllo ottimale separato non lo farà mai passerà contemporaneamente al controllo minimo , cosa che potrebbe essere un po 'confusa.

Con questo in mente - in caso di dubbio, dare un'occhiata a queue/optimal_io_sizee queue/minimum_io_size, e se la prima non è divisibile per quest'ultimo avvertimento, basta ignorare parted', e decidere per te se vuoi andare con un ottimale o un minimo di controllo .