Um disco acessado mais que outros durante a reconstrução do md RAID6

Question

Estou reconstruindo uma unidade de um RAID6 de 8 unidades (usando RAID de software 'md' para Linux) e notei que ela não parece estar indo tão rápido quanto possível, presumivelmente porque uma das unidades está sendo enviou duas vezes mais IOPS que os outros:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             155.00     77252.00         0.00      77252          0
sdb             153.00     76736.00         0.00      76736          0
sdc             154.00     77248.00         0.00      77248          0
sde             154.00     77248.00         0.00      77248          0
sdf             164.00     77288.00         0.00      77288          0
sdd             154.00     77248.00         0.00      77248          0
sdg             287.00     83160.00         0.00      83160          0
sdh             146.00         0.00     74240.00          0      74240

(o sdh está sendo reconstruído e o sdg está recebendo mais IOPS do que o esperado).

(Eu usei mdadm / dev / md1 --add / dev / sdh4 para adicionar a unidade de substituição, tendo falhado / removido o existente).

Coisas que (eu acho) eu eliminei:

1. Todas as unidades possuem layouts de partição idênticos (copiados usando o sgdisk).

2. sda-sdg são unidades idênticas com o mesmo número de modelo (sdh é novo).

3. Eu olhei para readahead, tamanho de bloco, multcount em todas as unidades e não consigo detectar qualquer diferença que o sdp possa ter comparado aos outros.

4. Uma reconstrução diferente na mesma máquina teve o mesmo problema (sendo o sdg acessado mais), então eu removi o bitmap de intenção de gravação antes desta vez, mas isso não ajudou.

5. A placa (ASRock P67 Extreme6) tem uma provisão SATA estranhamente heterogênea, com duas portas SATA3 e seis portas SATA6 (duas do chipset e quatro de uma interface Marvell SE9120 onboard). É possível que o sdg esteja na porta que também é compartilhada com o soquete eSATA, mas ele afirma estar usando o UDMA6 da mesma forma que os outros, por isso não consigo ver o efeito que isso teria.

Alguma idéia de por que os tps (IOPS) no SDG são o dobro dos outros?

UPDATE: Mais esclarecimentos:

1. As unidades são de 3TB Seagate Barracudas de 3TB (embora eu normalmente não me envolva com anedotas de marca de unidade, uma das oito unidades falhou e outras três (mas não a SDG) estão mostrando mal sinais (erros irrecuperáveis, vários setores realocados): esses não são os drives mais confiáveis que eu já usei. 'Tenho certeza que eles são PMR entediantes.

2. Depois que o RAID se recuperou, os acessos agora estão espalhados uniformemente entre todos os discos, com um número semelhante de IOPS para cada unidade. Assim, eu ficaria surpreso se a velocidade do link fosse relevante (embora eu possa estar fazendo 'otimizações' estranhas, suponho).

3. Eu não tive a chance de pegar a saída de 'iostat x' antes que o RAID tivesse terminado a recuperação, mas da memória, o sdg estava a 100% de utilização e tinha um grande tamanho de fila de pedidos (no 100s), enquanto os outros estavam com 50-60% de utilização e tinham um tamanho de fila de solicitações de um único dígito.

Acho que precisaria trocar sdg e outra unidade para eliminar totalmente se é o controlador / md ou a unidade.

UPDATE # 2: reconstrução diferente, mesmo problema

Desta vez estou reconstruindo o sdb:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda           13813.00     0.00  184.50    0.00    54.06     0.00   600.11    23.60  114.11  114.11    0.00   2.49  46.00
sdb               0.00 12350.50    0.00   97.50     0.00    48.62  1021.37     0.17    1.70    0.00    1.70   1.31  12.80
sdd           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     5.47   55.82   55.82    0.00   2.82  27.60
sdc           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     5.92   60.41   60.41    0.00   2.84  27.80
sde           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     6.11   62.39   62.39    0.00   3.02  29.60
sdf           12350.50     0.00   97.50    0.00    48.62     0.00  1021.37    14.56  149.33  149.33    0.00   3.92  38.20
sdg           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     7.18   73.31   73.31    0.00   3.16  31.00
sdh           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     5.27   53.80   53.80    0.00   2.88  28.20

Como você pode ver, o sda está obtendo muito mais acessos do que os outros (eu estou limitando-o para que o sda não esteja atingindo 100% de utilização, embora o faça se eu não o fizer). Curiosamente, o 'avgrq-sz' (Tamanho médio da requisição) de sda é menor, sugerindo que os acessos extras são muito menores. Agora eu só preciso encontrar uma maneira de descobrir o que eles são!

    

Answer 1

Meu palpite inicial era de que md havia identificado um problema com sdg e estava tentando extrair dados dele "mais cedo" para que ele pudesse ser substituído também.

Não é assim que md funciona (alguns controladores de hardware podem fazer isso - inseguro).

Muitas unidades em uma matriz diminuem as recriações ^{( pdf )} - de uma perspectiva reconstruir , menos unidades na matriz são "melhores".

Uma exploração adicional leva a uma possível conclusão e a algumas perguntas subsequentes:

• qual o tamanho das unidades?
• de que tipo eles são - enterprise ou desktop?
• que marca são eles - WD, Seagate, Hitachi, outros, um mix?
• que tipo de unidades estão no array - PMR ou SMR?

A partir desta revisão de um disco da Seagate, parece que as reconstruções com SMR (que são denser-packed ) são invulgarmente inconsistentes em termos de velocidade, sendo que o PMR é mais consistente.

Minha conclusão provisória é que

1. diferentes velocidades de porta SATA não estão ajudando aqui - isso, eu acho, deveria ser óbvio para todos os envolvidos:)
2. você tem drives com marcas diferentes na matriz ou são muito grandes ou não são projetados para lidar com recriações " melhor " (PMR) - ou uma combinação dos itens acima