RAID5 não faz spindown depois de crescer (ext4lazyinit)

1

Eu tinha um array RAID5 consistindo de discos 3x5TB montados usando mdadm . Além disso, criei uma camada de criptografia LUKS/dmcrypt e formatei o dispositivo criptografado com ext4 . Eu quero que os discos girem para baixo em caso de inatividade.

Tudo funcionou bem durante vários meses, os discos estavam girando depois de um minuto de inatividade. Agora, adicionei um quarto disco de 5 TB do mesmo tipo ao array por sudo mdadm --add /dev/md0 /dev/sdb1 , depois fiz o array crescer naquele disco ( mdadm --grow /dev/md0 --raid-devices=4 ) e, finalmente, desenvolvi o sistema de arquivos com sudo fsck -f /dev/mapper/raid5 e sudo resize2fs /dev/mapper/raid5 .

Nenhum erro ocorreu e a matriz agora é 5 TB maior. Mas os discos não estão mais girando. A máquina funciona 24 horas por dia, 7 dias por semana, não está usando os discos, mas apesar de esperar alguns dias, os discos ainda estão funcionando o tempo todo.

iotop mostra ocorrências frequentes de ext4lazyinit , que aparecem por menos de um segundo a cada poucos segundos. Eu não percebi isso antes de crescer o sistema de arquivos. Então, provavelmente são as tarefas que mantêm os discos acordados? Mas como posso forçar o ext4lazyinit a completar sua tarefa?

    
por LukeLR 27.03.2018 / 18:45

1 resposta

1

ext4lazyinit está fazendo exatamente o que diz - está inicializando o restante do sistema de arquivos de maneira preguiçosa. Ele faz isso para dar a aparência de produzir rapidamente um sistema de arquivos. Como você percebeu, ele tentará impactar o desempenho do sistema o mínimo possível, e isso significa que levará muito tempo para ser concluído.

A primeira opção é aguardar - ela será interrompida eventualmente e seus discos deverão retornar ao modo inativo.

Outra opção é desmontar o sistema de arquivos e montá-lo com frequência com -o init_itable=0 , forçando o init preguiçoso a ser mais proativo, mas o desempenho será prejudicado. O valor padrão é 10, portanto, se o desempenho for importante nesse meio tempo,  talvez tente valores entre. ( ref )

init_itable=n    The lazy itable init code will wait n times the number of milliseconds
                 it took to zero out the previous block group's inode table. This
                 minimizes the impact on the system performance while file system's
                 inode table is being initialized.

Uma terceira opção é desativar a inicialização itable - embora na minha opinião, esta é uma opção ruim, especialmente para um sistema de arquivos que está em produção e presumivelmente tem dados importantes sobre ele (é por isso que você está usando um RAID ?)

Você pode fazer isso com a opção noinit_itable :

noinit_itable     Do not initialize any uninitialized inode table blocks in the
                  background. This feature may be used by installation CD's so that the
                  install process can complete as quickly as possible; the inode table 
                  initialization process would then be deferred until the next time the
                  file system is unmounted.

Editar: estimativas de duração.

Tenha em mente que os discos têm um desempenho de gravação de ~ 110-120MB / s ... Você está executando uma matriz, portanto, em um mundo ideal, haverá uma melhoria de ~ 330-360MB / s ( 110 * (n - 1) ) . Eu também vi o RAID5 rodar muito mais lento (~ 40MB / s em 8 discos com um controlador RAID - doloroso).

Com uma estimativa de 110MB / s, você espera cerca de 12 horas para um init de 5TB com um disco inteiro.

    
por 27.03.2018 / 18:54