SSD, Apagar Tamanho do Bloco e LVM: PV no dispositivo bruto, Alinhamento

Question

Eu quero instalar um novo SSD e usar o dispositivo como um PV para o LVM - em outras palavras: não pretendo colocar nem mesmo uma partição neste dispositivo. Portanto, alinhar partições nos blocos de apagamento não é necessário.

Pergunta (s)

É suficiente definir --dataalignment para o tamanho do bloco de apagamento quando pvcreate ing e --physicalextentsize para um múltiplo do tamanho do bloco de apagamento quando vgcreate ing?

Então, supondo que meu SSD tenha um tamanho de bloco de apagamento de 1024k, é aceitável

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

Mais alguma coisa para levar em conta?

Supondo que eu coloquei sistemas de arquivos ext4 nos LVs neste VG, seria uma boa idéia alinhar as extensões ext4 com o tamanho LVM-PE, certo? Então ext4-extents deve ser do mesmo tamanho ou um múltiplo do tamanho do LVM-PE?

Obrigado por qualquer esclarecimento!

    

Answer 1

Sim, também verifiquei todos os layouts em disco do MBR / PBR / GPT / MD / LVM e cheguei à mesma conclusão.

Para o seu caso (LVM no disco bruto), se o LVM-PE (extensão física) estiver alinhado com 1MB com pvcreate, você pode ter certeza de que toda a alocação de dados será alinhada, contanto que você mantenha o tamanho da alocação como (1MB * N).

Já que tanto "vgcreate -s" quanto "lvcreate -L" manipulam tamanho-sem-unidade como valor de MB por padrão, você provavelmente não precisa se importar muito com o alinhamento depois de ter feito o pvcreate corretamente. Apenas certifique-se de não dar tamanho em% / PE (para lvcreate -l) e B (byte) / S (512B - setor é sempre 512B no LVM) / K (KB) (para vgcreate -s e lvcreate -L).

=== adicionado para esclarecimento ===

Assim como um acompanhamento, enquanto um SSD pode ter 1024KB de tamanho de bloco como um dispositivo inteiro, cada tamanho de bloco de apagamento de chip flash interno / tamanho de página de rw é provavelmente de 32KB-128KB / 512B-8KB.

Embora isso dependa do controlador de cada SSD, a penalidade de E / S devido ao ciclo extra de leitura-modificação-gravação provavelmente não acontecerá, desde que você mantenha sua escrita alinhada para apagar o tamanho de bloco de cada chip interno, que é 32KB- 128 KB no exemplo acima. É só que você deseja que a solicitação de gravação única seja grande o suficiente (= tamanho do bloco de exclusão de SSD como um dispositivo inteiro), para que você possa esperar um desempenho melhor ao conduzir eficientemente todos os chips / canais internos.

Meu entendimento é que o alinhamento de 1024 KB é apenas uma medida de segurança, já que a função do chip do controlador varia de acordo com um fornecedor, e as especificações do chip flash mudam rapidamente. É mais importante que a solicitação de gravação no nível do sistema operacional seja feita em um pacote grande (1024 KB, neste caso).

Agora, tendo dito isso, fazer o mkfs (8) em um bloco LVM alinhado em 1MB quase certamente quebrará o alinhamento de 1MB para dados / metadados em nível de sistema de arquivos. A maioria dos sistemas de arquivos só se preocupa em fazer alinhamento 4KB, então provavelmente não é perfeito para SSDs (mas, IIRC, fs recentes como btrfs tentam manter um alinhamento de 64KB + ao alocar blocos contíguos internos). Mas muitos fs têm um recurso para empacotar gravações (ex: configuração de tamanho de faixa) para obter desempenho fora do RAID, de modo que pode ser usado para tornar a solicitação de gravação para SSD quase ótima.

Eu realmente quero apoiar minha declaração com dados reais, mas foi realmente difícil provar que o controlador SSD atual é tão inteligente, e não mostrará muita degradação de desempenho uma vez que tanto o tamanho do alinhamento quanto o tamanho da gravação são "grandes o suficiente". Apenas certifique-se de que não esteja mal alinhado (evite < 4KB-aligment a todo custo) e não muito pequeno (1024 KB é grande o suficiente).

Além disso, se você realmente se importa com a penalidade de IO, verifique novamente desativando o cache do dispositivo e comparando-o com o teste de reescrita de leitura-gravação sincronizado.

    

Answer 2

No meu entender, os padrões já são bons o suficiente. Eu não acho que você precisa se preocupar com a opção --dataalignment como o LVM tentará automaticamente alinhar tudo com base nos valores exportados sysfs, veja a opção "data_alignment_detection" no 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

Além disso, não é necessário especificar um physicalextentsize para vgcreate, já que o padrão já é de 4MB.