Alignement correct des partitions sur un disque dur au format avancé à l'aide de Parted

15

Je crée d'abord une partition correctement alignée dans une nouvelle table GPT à l'aide de parted en spécifiant des pourcentages pour le début et la fin de la partition:

# 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

Notez que ce disque utilise le format avancé, mais rapporte correctement la taille du secteur physique 4096Bà Parted. Examinons-le à nouveau, en utilisant les secteurs comme 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
  • Pourquoi a-t-il démarré la partition 2048set non 34squel est le premier secteur possible ?
  • 34sn'est pas un secteur de départ correctement aligné si la taille du secteur physique est 4096Bet la taille du secteur logique (qui est celle que vous spécifiez dans Parted) est 512B. Un secteur de départ correctement aligné est divisible par 8(puisque la taille du secteur physique / la taille du secteur logique = 8). Mais cela signifie que 40sc'est le premier secteur de départ correctement aligné, mais il n'est pas utilisé. Pourquoi?

Si nous essayons de créer une partition de 100MiBcapacité correctement alignée à partir 40sd'une nouvelle table de partition 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)
  • Nous recevons toujours l' Warning: The resulting partition is not properly aligned for best performance.avertissement, même si les 40s204840 ( 204839s+ 1) sont tous les deux divisibles par 8. Pourquoi?
Effacé
la source

Réponses:

23

Parted est juste trop conservateur. La pratique habituelle de nos jours consiste à aligner les partitions sur des limites de 1 Mo (secteur 2048) car cela fonctionne sur les disques au format avancé, sur certains types de configurations RAID qui nécessitent un alignement et sur la plupart des SSD. Pour un disque au format avancé, tant que l'alignement est sur un multiple de 8, tout va bien et 2048 est un multiple de 8. L'espace disque perdu est minable - 0,0000336% de votre espace disque total, si je le faisais le calcul à droite et n'a rien mal écrit. Alors ne vous en faites pas; utilisez simplement l'alignement de 1 Mo.

Rod Smith
la source
Oui, l'espace disque perdu n'a pas d'importance pour moi. Je voulais juste savoir que j'avais bien compris les choses. Je vérifie actuellement le code source de Parted, mais cela prend un peu plus de temps que je n'en ai. Je vais donc continuer et utiliser l'alignement 1 Mo. Merci d'avoir encore une fois aidé!
Supprimé
1
Il vaut la peine de mentionner qu'il ne s'agit pas simplement de la prudence de la séparation, mais plutôt d'une limitation de la couche de blocs Linux. Les lecteurs ATA ne fournissent aucun optimal_io_sizeindice. Par conséquent, il n'y a aucun moyen de faire la distinction entre les périphériques ATA «hérités» qui ne fournissent pas alignment_offsetet par alignment_offsetdéfaut à 0 et ceux qui en ont alignment_offset=0. fdisk / parted utilise un alignement de partition de 1 Mo pour ces disques.
roolebo
1
Et le nombre lui-même - l'alignement de partition de 1 Mo semble provenir du comportement de Windows Vista , comme référencé dans la validation partagée .
roolebo
1

J'ajouterai probablement que sous Linux, on peut arriver dans une situation où il est partedpossible de ne jamais réussir un contrôle d'alignement optimal et minimal en même temps.

La raison en est que parted(au moins à partir de la version 3.2) s'appuie sur libblkid, qui à son tour rapporte les valeurs de /sys/block/<disk>/queue/minimum_io_sizeet /sys/block/<disk>/queue/optimal_io_size(voir io-limits.txt ).

Ainsi, alors que pour un disque au format avancé, le premier sera probablement quelque chose comme 4k, le second peut avoir une valeur folle - par exemple 65535 * 512 == 33553920.

Maintenant, si nous regardons le code source - l'alignement "correct" ou "meilleures performances" est défini par la formule dans parted.c :: partition_align_check () :

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

d'où grain_sizevient la taille du bloc d'E / S ci-dessus, geom.startest notre décalage de partition, et le décalage d'alignement pa->offsetest assez souvent nul.

Par défaut, parted supposerait que 1 MiB soit optimal et ~ 4k la taille minimale (pas tout à fait, c'est un peu une simplification) de la taille du bloc, donc ces valeurs seraient corrélées; cependant, s'il en libblkiddécide autrement, il a partedtendance à lui faire confiance et à remplacer cette valeur par défaut de 1 Mio par la valeur trouvée dans /sys/block/<disk>/queue/optimal_io_size. (En même temps, vous /sys/block/<disk>/queue/minimum_io_sizeobtiendrez probablement le même 4096 B.)

Dans ce cas, le contrôle optimal séparé ne passera jamais simultanément avec le contrôle minimal , ce qui pourrait être un peu déroutant.

Dans cet esprit - en cas de doute, jetez un œil à queue/optimal_io_sizeet queue/minimum_io_size, si le premier n'est pas divisible par le second, ignorez simplement l'avertissement séparé et décidez vous-même si vous voulez opter pour un contrôle optimal ou minimal. .

ジ ョ ー ジ
la source