Acabei de substituir uma unidade de falha na minha matriz de raid6 (consistindo em 8 unidades) durante a recuperação. Observei algo estranho no iostat. Todas as unidades estão obtendo as mesmas velocidades (como esperado), exceto por uma unidade (sdi) que está constantemente lendo mais rápido do que as outras.
Ele também está lendo cerca de um oitavo mais rápido, o que pode ter algo a ver com o total de oito unidades no array, mas não sei por que ...
Isso foi verdade durante toda a recuperação (sempre a mesma leitura da unidade foi mais rápida que todas as outras) e olhando as estatísticas totais da recuperação, todas as unidades leram / gravaram praticamente a mesma quantidade, exceto para sdi que leram uma oitavo mais.
Algumas estatísticas de iostat têm uma média de 100s:
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sdb 444.80 26.15 0.00 2615 0
sdb1 444.80 26.15 0.00 2615 0
sdc 445.07 26.15 0.00 2615 0
sdc1 445.07 26.15 0.00 2615 0
sdd 443.21 26.15 0.00 2615 0
sdd1 443.21 26.15 0.00 2615 0
sde 444.01 26.15 0.00 2615 0
sde1 444.01 26.15 0.00 2615 0
sdf 448.79 26.15 0.00 2615 0
sdf1 448.79 26.15 0.00 2615 0
sdg 521.66 0.00 26.15 0 2615
sdg1 521.66 0.00 26.15 0 2615
sdh 443.32 26.15 0.00 2615 0
sdh1 443.32 26.15 0.00 2615 0
sdi 369.23 29.43 0.00 2942 0
sdi1 369.23 29.43 0.00 2942 0
Alguém pode oferecer uma explicação sensata?
Quando eu descobri que era ~ exatamente um oitavo mais rápido eu percebi que isso tinha a ver com a paridade, mas isso realmente não fazia muito sentido (eu não sei sobre a implementação específica do raid 6 no mdadm, mas para um ele certamente pode armazene toda a paridade em uma unidade ...).
ATUALIZAÇÃO:
Bem, eu substitui outra unidade agora mesmo (mesma matriz) e estou vendo exatamente os mesmos resultados, mas desta vez com uma unidade diferente lendo mais rápido (na verdade, é a unidade que eu adicionei para a última recuperação que decidiu que quer fazer mais trabalho).
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sdb 388.48 24.91 0.00 2490 0
sdb1 388.48 24.91 0.00 2490 0
sdc 388.13 24.91 0.00 2491 0
sdc1 388.13 24.91 0.00 2491 0
sdd 388.32 24.91 0.00 2491 0
sdd1 388.32 24.91 0.00 2491 0
sde 388.81 24.91 0.00 2491 0
sde1 388.81 24.91 0.00 2491 0
sdf 501.07 0.00 24.89 0 2489
sdf1 501.07 0.00 24.89 0 2489
sdg 356.86 28.03 0.00 2802 0
sdg1 356.86 28.03 0.00 2802 0
sdh 387.52 24.91 0.00 2491 0
sdh1 387.52 24.91 0.00 2491 0
sdi 388.79 24.92 0.00 2491 0
sdi1 388.79 24.92 0.00 2491 0
Estes são drives de 4k (mas como todos os drives fazem (ou pelo menos fizeram) eles reportam setores de 512 bytes). Então imaginei que poderia ter alinhado as partições de alguma forma (quais implicações poderiam ter, não sei, depende de como o mdadm funciona e o tamanho da distribuição, eu acho, de qualquer maneira, fácil de verificar):
debbie:~# fdisk -l -u /dev/sd[bcdefghi] | grep ^/dev/sd
/dev/sdb1 2048 3906988207 1953493080 fd Linux raid autodetect
/dev/sdc1 2048 3906988207 1953493080 fd Linux raid autodetect
/dev/sdd1 2048 3906988207 1953493080 fd Linux raid autodetect
/dev/sde1 2048 3906988207 1953493080 fd Linux raid autodetect
/dev/sdf1 2048 3907024064 1953511008+ fd Linux raid autodetect
/dev/sdg1 2048 3907024064 1953511008+ fd Linux raid autodetect
/dev/sdh1 2048 3906988207 1953493080 fd Linux raid autodetect
/dev/sdi1 2048 3906988207 1953493080 fd Linux raid autodetect
f e g são os novos drives e parecem ser um pouco maiores, mas todos começam no mesmo setor (todos os drives do mesmo fazem um modelo (e no mesmo controlador), mas os novos são comprados ~ 6 meses depois do resto).