SSD, Erase Block Size & LVM: PV sur le périphérique brut, alignement

Je veux installer un nouveau SSD et utiliser l'ensemble de l'appareil comme PV pour LVM - en d'autres termes: je ne prévois pas de mettre même une partition sur cet appareil. Il n'est donc pas nécessaire d'aligner les partitions sur les blocs d'effacement.

Des questions)

Est-il suffisant de définir --dataalignmentla taille du bloc d'effacement lors de l' pvcreateing et --physicalextentsizeun multiple de la taille du bloc d'effacement lors de l' vgcreateing?

Donc, en supposant que mon SSD a une taille de bloc d'effacement de 1024k, est-il correct de

• pvcreate --dataalignment 1024k /dev/ssd
• vgcreate --physicalextentsize $(( x * 1024 ))k ...

Autre chose à prendre en compte?

En supposant que je mettrais des systèmes de fichiers ext4 sur les LV dans ce VG, ce serait une bonne idée d'aligner les extensions ext4 sur la taille LVM-PE, non? Les extensions ext4 doivent donc avoir la même taille ou un multiple de LVM-PE?

Merci pour toute précision!

Oui, j'ai également vérifié toute la disposition sur disque de MBR / PBR / GPT / MD / LVM et suis arrivé à la même conclusion.

Pour votre cas (LVM sur disque brut), si LVM-PE (étendue physique) est aligné à 1 Mo avec pvcreate, vous pouvez être sûr que toute autre allocation de données sera alignée, tant que vous gardez la taille d'allocation à (1 Mo * N) .

Étant donné que "vgcreate -s" et "lvcreate -L" gèrent par défaut la taille sans unité comme valeur en Mo, vous n'aurez probablement pas à vous soucier de l'alignement une fois que vous aurez fait votre pvcreate correctement. Assurez-vous simplement de ne pas donner la taille en% / PE (pour lvcreate -l) et B (octet) / S (512B - le secteur est toujours 512B en LVM) / K (KB) (pour vgcreate -s et lvcreate -L).

=== ajouté pour clarification ===

À titre de suivi, alors qu'un SSD peut avoir une taille de bloc d'effacement de 1024 Ko en tant que périphérique entier, la taille de bloc d'effacement / taille de page de chaque puce flash interne est probablement d'environ 32 Ko-128 Ko / 512B-8 Ko.

Bien que cela dépende du contrôleur de chaque SSD, une pénalité d'E / S due à un cycle de lecture-modification-écriture supplémentaire ne se produira probablement pas tant que vous gardez votre écriture alignée pour effacer la taille de bloc de chaque puce interne, qui est de 32 Ko à 128 Ko ci-dessus. exemple. C'est juste que vous voulez que la demande d'écriture unique soit suffisamment grande (= effacer la taille de bloc du SSD dans son ensemble), donc vous pouvez vous attendre à de meilleures performances en pilotant efficacement toutes les puces / canaux internes.

Ma compréhension est que l'alignement de 1024 Ko n'est qu'une mesure de sécurité, car la fonction de la puce du contrôleur varie selon le fournisseur et les spécifications de la puce flash changent rapidement. Il est plus important que la demande d'écriture au niveau du système d'exploitation soit effectuée dans un grand ensemble (1024 Ko, dans ce cas).

Maintenant, cela dit, faire mkfs (8) sur un bloc LVM aligné à 1 Mo cassera presque certainement l'alignement de 1 Mo pour les données / métadonnées au niveau du système de fichiers. La plupart des systèmes de fichiers ne se soucient que de l'alignement 4KB, donc ce n'est probablement pas parfait pour les SSD (mais, IIRC, les fs récents comme btrfs essaient de garder l'alignement 64KB + lors de l'allocation du bloc contigu interne). Mais de nombreux fs ont une fonctionnalité pour regrouper les écritures (ex: configuration de taille de bande) pour obtenir des performances hors du RAID, de sorte qu'elles peuvent être utilisées pour rendre la demande d'écriture sur le SSD presque optimale.

Je veux vraiment soutenir ma déclaration avec des données réelles, mais c'était vraiment difficile à prouver car le contrôleur SSD d'aujourd'hui est si intelligent et ne montrera pas beaucoup de dégradation des performances une fois que la taille d'alignement et la taille d'écriture sont "assez grandes". Assurez-vous simplement qu'il n'est pas mal aligné (évitez l'alignement <4KB à tout prix) et pas trop petit (1024KB est assez grand).

De plus, si vous vous souciez vraiment de la pénalité d'E / S, revérifiez en désactivant le cache de l'appareil et l'analyse comparative avec le test de lecture-écriture-réécriture synchronisé.

À ma connaissance, les valeurs par défaut sont déjà assez bonnes. Je ne pense pas que vous ayez à vous soucier de l'option --dataalignment car LVM essaiera automatiquement d'aligner tout en fonction des valeurs exportées par sysfs, voir l'option "data_alignment_detection" dans lvm.conf:

# By default, the start of a PV's data area will be a multiple of
# the 'minimum_io_size' or 'optimal_io_size' exposed in sysfs.
# - minimum_io_size - the smallest request the device can perform
#   w/o incurring a read-modify-write penalty (e.g. MD's chunk size)
# - optimal_io_size - the device's preferred unit of receiving I/O
#   (e.g. MD's stripe width)
# minimum_io_size is used if optimal_io_size is undefined (0).
# If md_chunk_alignment is enabled, that detects the optimal_io_size.
# This setting takes precedence over md_chunk_alignment.
# 1 enables; 0 disables.
data_alignment_detection = 1

De plus, il n'est pas nécessaire de spécifier une taille physique à vgcréer car la valeur par défaut est déjà 4 Mo.