Raid5 lento resync com unidades WD Green [closed]

Question

A questão

Por que minha ressincronização inicial é tão lenta? Inicialmente, cat /proc/mdstat reportou ~ 30000K/sec .

• Em seguida, aumentei /sys/block/md0/md/stripe_cache_size de 256 para 16384 . Isso aumentou a velocidade para ~50000K/sec .
• Alterei /proc/sys/dev/raid/speed_limit_min de 1000 para 100000 e /proc/sys/dev/raid/speed_limit_max de 200000 para 400000 , mas isso não ajudou.

O que mais posso fazer para acelerar as coisas?

• Este tópico sugere a substituição de unidades Western Digital Green por algo diferente. Isso não é uma opção para mim.
• A execução de smartctl -t short /dev/sd[bcd] e posterior smartctl -l selftest /dev/sd[bcd] não revelou erros.
• Vários recursos que encontrei no tópico ( 1 , 2 ) não são muito específicos sobre como (quais comandos) alterar certas configurações, eles não explicam muito bem o que eles fazem & porque eles ajudam.

Alguns antecedentes

Como eu configuro o array de ataque

Acabei de adicionar três unidades Western Digital SATA de 2TB (suas unidades "verdes") ao meu servidor Ubuntu 14.04. Eles são /dev/sd[bcd] .

Eu decidi usá-los em um array raid5 e configurar tudo assim:
1) Crie uma partição em cada disco:
fdisk /dev/sdb (mesmo para sdc e sdd )

Baseado em este post de blog escolhi 2048 e 3907029128 como o respectivo primeiro e último setor em cada disco. Esses números são divisíveis por 4, já que essas unidades são unidades de setor de 4K.

O tipo fs foi definido como da (Non-FS data) , de acordo com o post do blog, que diz

This stops distribution auto-mount startup scripts for searching for superblocks on drives marked as “fd” and trying to mount them up in a funny order.

Como o RAID Array não é essencial para inicializar o sistema, isso faz sentido para mim.

2) crie uma matriz de raid usando mdadm : mdadm --create --verbose /dev/md0 --level=5 --chunk=2048 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --spare-devices=0 --force

A opção --chunk=2048 também foi inspirada no mesma postagem no blog ," tendo [ing] em mente a lógica 'deve ser divisível por 4'. "

As opções --spare-devices=0 --force são criadas por mim, pois sem elas o comando mdadm iniciaria o processo de ressincronização inicial, mas rapidamente diminuiria para < 200K/sec e, em seguida, sairia com uma mensagem em /var/mail/root that /dev/sdd "pode ter falhado". Depois disso, a saída de mdadm --detail /dev/md0 mostraria que /dev/sdd1 foi movido para ser uma unidade sobressalente.
Desde a adição dessas opções, a ressincronização continua em execução. Primeiro diminuiu para < 100K/sec , mas a velocidade aumentou para cerca de 30000K/sec e ficou lá.

Sobre o processo de ressincronização em execução

atop revela que /dev/sdd é o mais lento

DSK |          sdd  | busy    103% | read     930  | write    304 | KiB/r    512  |              |  KiB/w    512 | MBr/s  46.50 |  MBw/s  15.20 | avq   112.12 |  avio 8.10 ms |
DSK |          sdc  | busy     85% | read     942  | write    384 | KiB/r    508  |              |  KiB/w    410 | MBr/s  46.75 |  MBw/s  15.40 | avq    20.59 |  avio 6.21 ms |
DSK |          sdb  | busy     73% | read     942  | write    387 | KiB/r    508  |              |  KiB/w    411 | MBr/s  46.75 |  MBw/s  15.55 | avq    17.31 |  avio 5.31 ms |

Sobre as unidades WD Green

Todas as unidades foram compradas em um horário diferente (por isso, suspeito que sejam de diferentes tiragens de produção, com meses de diferença). /dev/sdb e /dev/sdc são as mais novas e têm 64MB de cache. /dev/sdd tem 32MB de cache.

    

Answer 1

Apenas alguns minutos depois de postar essa pergunta, a ressincronização inicial se cancelou novamente, movendo o mais antigo dos meus discos para um local "sobressalente", antes mesmo de atingir 100%.

Embora o dispositivo não revelasse nenhum problema de smartclt , descobriu-se que ele estava de fato quebrado. Isso foi estabelecido por badblocks , que revelou milhares de setores quebrados. Substituir esse disco por um novo corrigiu o problema para mim.