![md raid5 extremamente lento no descarte](https://rvso.com/image/761638/md%20raid5%20extremamente%20lento%20no%20descarte.png)
Olá a todos os especialistas em MD RAID
Rodando Centos 8 (com todas as atualizações mais recentes, kernel 4.18.0-240.1.1.el8_3.x86_64) onde tenho 3x2T Samsung SSD 860 QVO 2TB em raid5 (para ser usado como base para algumas VMs KVM) e quando faço algo que envolve descarte, não é apenas lento, é muito além de utilizável. Eu criei um LV 1.5T e fiz "mkfs.ext4" que, após 4h o estágio de descarte me disse "Descartando blocos de dispositivos: 10489856/409148416" e no começo eu estava pensando "4h para 25%, isso é uma merda", mas depois Percebi que são apenas 2,5%, então estamos falando de uma semana!
Eu interrompi o ataque e fiz blkdiscard nas 3 unidades individuais, demorando cerca de 18 segundos cada.
O hardware é um HP Proliant DL380p Gen8 com um controlador Smart Array P420i (sem drivers especiais, todos usando drivers Centos padrão) que configurei para o modo HBA, portanto deve ser apenas uma passagem (o descarte não é suportado se estiver usando hw ataque).
Depois de fazer descarte nos dispositivos criei o raid novamente com
mdadm --create /dev/md20 --level=5 --raid-devices=3 --chunk=64 /dev/sd{b,d,e}1
Deixei durante a noite para sincronizar. Aí criei uma vg e testei a criação de lv, demorou 7 minutos para descartar 100M
root@terrok:~ # lvcreate -nDELME -L100M vgssd2 && date && time mkfs.ext4 /dev/vgssd2/DELME && date && time lvremove -f /dev/vgssd2/DELME;date
Logical volume "DELME" created.
Mon Dec 21 12:47:42 EST 2020
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: f7cf3bb6-2764-4eea-9381-c774312f463b
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
real 7m20.095s
user 0m0.004s
sys 0m0.195s
Mon Dec 21 12:55:02 EST 2020
Logical volume "DELME" successfully removed
real 7m17.881s
user 0m0.018s
sys 0m0.120s
Mon Dec 21 13:02:20 EST 2020
root@terrok:~ #
Como comparação no mesmo sistema também tenho dois WDC WDS100T2B0A-00SM50 (1T SSD) em raid1 e aí o descarte funciona muito mais rápido, 4 segundos para 10G.
Peguei então dois SSDs Samsung e fiz um raid1 deles, a toda velocidade no descarte. Repetido para as outras duas combinações de unidades e sem problemas. Para mim, isso aponta para algum problema com o raid5. Por enquanto eu tenho dois SSDs em raid1 com um hot spare e isso pelo menos funciona, mas é claro que há 2T a menos de espaço do que eu contava.
Alguma sugestão sobre o que posso fazer para tornar isso utilizável com o raid5?
Responder1
Conforme demonstrado pelos seus testes, o RAID5 é realmente uma operação mais intensiva do que um simples array RAID 1. Porque o RAID 1 está literalmente apenas sincronizando entre dois discos.
O RAID 5, por outro lado, precisa fazer todos esses cálculos entre três discosepará-los. Isso dá muito trabalho, pelo menos em comparação com um array RAID 1 "simples".
Além disso, como barra lateral, as unidades QVO não são ideais para cargas como manutenção de VMs, que normalmente as atividades das unidades são geralmente valiosas. Nem matrizes de paridade como RAID 5 e assim por diante. Você pode querer reconsiderar suas estratégias de implantação com isso dito e a situação com o próprio RAID5.
Responder2
Acabei de abordar esse problema também. Pesquisei o driver do raid5 e descobri que o raid5 divide a solicitação de descarte recebida em solicitações de descarte de 4k nos dispositivos subjacentes. Além disso, ele está quebrado há um bom tempo, de modo que praticamente ignora devices_handle_discard_safely. Como resultado, todos os descartes de 4k são feitos de forma sincronizada com o dispositivo subjacente, tornando a operação ainda mais lenta no total. nota lateral: Em breve trarei isso para o LKML, então você pode ficar ligado lá. Não estou familiarizado com nenhuma solução alternativa disponível para os kernels existentes.