Erro de E / S do buffer no dispositivo md - não é possível identificar o disco com falha

5

A sincronização do meu mestre de postgres com o servidor escravo resultou em erros de E / S de gravação no escravo (journalctl):

Aug 18 03:09:23 db01a kernel: EXT4-fs warning (device dm-3): 
**ext4_end_bio:330: I/O error -5 writing to inode 86772956 (offset 905969664 size 8388608 starting block 368694016)**                  
Aug 18 03:09:23 db01a kernel: buffer_io_error: 326 callbacks suppressed  

....

Ler o arquivo afetado também não funciona:

cat base/96628250/96737718  >> /dev/null
cat: 96737718: Input/output error

O kernel do linux (Ubuntu 16.04 4.4.0-87-generic) não deve chutar a unidade afetada da matriz automaticamente?

Como é um Raid6 (LVM e ext4 no topo) eu já tentei sobrescrever cada SSD algumas vezes com badblocks para provocar o erro (removi um disco após o outro da raid para isso), infelizmente sem sucesso. / p>

smartctl diz que um disco teve erros antes (os outros estão limpos):

 smartctl -a /dev/sda
 ID# ATTRIBUTE_NAME         FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

 5  Reallocated_Sector_Ct   0x0033   099   099   010    Pre-fail  Always       -       2

179 Used_Rsvd_Blk_Cnt_Tot   0x0013   099   099   010    Pre-fail  Always       -       2

183 Runtime_Bad_Block       0x0013   099   099   010    Pre-fail  Always       -       2

187 Uncorrectable_Error_Cnt 0x0032   099   099   000    Old_age   Always       -       3

195 ECC_Error_Rate          0x001a   199   199   000    Old_age   Always       -       3

Mas reescrevendo todo o disco com badblocks -wsv funcionou sem erros.

Como é um servidor muito importante para mim, substituí todo o servidor por um modelo diferente, mas o erro persistiu. Estou correto em pensar que é provavelmente um problema de disco?

Existe alguma maneira de saber qual disco é afetado, talvez calculando?

EDIT: Para esclarecimento: O que não estou conseguindo é como a sincronização inicial de dados de 1,5 TB do mestre para o escravo pode resultar em dois erros de E / S irrecuperáveis, mas executando manualmente testes destrutivos de leitura e gravação em cada SSD envolvido conclui sem qualquer erro.

EDIT2: Saída do lsblk (idêntico para sda-sdf); pvs; vgs; lvs;

lsblk:
sda1                        8:16   0 953.9G  0 disk                                                
├─sda1                     8:17   0   4.7G  0 part                                                
│ └─md0                    9:0    0   4.7G  0 raid1                                               
└─sda5                     8:21   0 949.2G  0 part                                                
  └─md1                    9:1    0   2.8T  0 raid6                                               
    ├─vgdb01a-lvroot     252:0    0  18.6G  0 lvm   /                                             
    ├─vgdb01a-lvvar      252:1    0    28G  0 lvm   /var                                          
    ├─vgdb01a-lvtmp      252:2    0   4.7G  0 lvm   /tmp                                          
    └─vgdb01a-lvpostgres 252:3    0   2.6T  0 lvm   /postgres 

pvs: 
PV         VG      Fmt  Attr PSize PFree  
/dev/md1   vgdb01a lvm2 a--  2.78t 133.64g

vgs:
VG      #PV #LV #SN Attr   VSize VFree  
vgdb01a   1   4   0 wz--n- 2.78t 133.64g

lvs:
lvs
LV         VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
lvpostgres vgdb01a -wi-ao----  2.60t                                                    
lvroot     vgdb01a -wi-ao---- 18.62g                                                    
lvtmp      vgdb01a -wi-ao----  4.66g                                                    
lvvar      vgdb01a -wi-ao---- 27.94g    

Atualização 2017-8-22

echo check > /sys/block/md1/md/sync_action
[Mon Aug 21 16:10:22 2017] md: data-check of RAID array md1
[Mon Aug 21 16:10:22 2017] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[Mon Aug 21 16:10:22 2017] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
[Mon Aug 21 16:10:22 2017] md: using 128k window, over a total of 995189760k.
[Mon Aug 21 18:58:18 2017] md: md1: data-check done.

echo repair > /sys/block/md1/md/sync_action    [Tue Aug 22 12:54:11 2017] md: requested-resync of RAID array md1
[Tue Aug 22 12:54:11 2017] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[Tue Aug 22 12:54:11 2017] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for requested-resync.
[Tue Aug 22 12:54:11 2017] md: using 128k window, over a total of 995189760k.
[2160302.241701] md: md1: requested-resync done.

e2fsck -y -f /dev/mapper/vgdb01a-lvpostgres
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vgdb01a-lvpostgres: 693517/174489600 files (1.6% non-contiguous), 608333768/697932800 blocks

Atualização 2017-8-22 2 Saída de lsscsi e todo disco smartctl em pastebin: link

    
por Toni 18.08.2017 / 17:26

1 resposta

1

UPDATE-8/22

Se você quiser resolver esse problema rapidamente, basta substituir as duas unidades que têm as piores estatísticas de smartctl e reavaliam. Quando você estiver fora dos blocos reservados, sua unidade será EOL. Vendo que compramos tudo de uma vez, eles tendem a falhar na mesma época. Então não importa qual é o bloco ruim está preso a. Depois de substituir os dois piores criminosos (o que significa substituir um e ressincronizar e repetir), você terá aumentado a saúde geral do array, provavelmente substituído o disco de reclamação e reduzido drasticamente o risco de uma falha dupla, em que você perderá tudo.

No final do dia, seus dados valem mais do que algumas centenas de dólares.

ENDUPDATE-8/22

UPDATE-8/21

Toni Sim, seu post original tem espaço para melhorias. Dados esses fatos, esta é a conclusão a que cheguei. Também não ficou claro até agora que você já sofreu corrupção de dados.

Seria útil incluir os cabeçalhos com a saída smartctl. Isso é mais fácil no scsi, o sg_reassign irá dizer quantos blocos livres você tem para reatribuir, uma vez que vai para zero, você está pronto. Vendo que o smartctl está relatando "prefail" em várias categorias, parece que você também acabou em breve.

Em breve, você receberá erros de mídia pesada e o MD kickará a unidade. O fsck seria uma boa ideia nesse meio tempo. Quando as unidades falham em uma gravação, elas reatribuem o destino do bloco de blocos livre; quando você acaba, isso se torna um erro de mídia irrecuperável.

Também habilite "scrubber de disco" no MD e execute-o no cron semanalmente, ele irá ler e reescrever cada setor e desabilitar isso antes que ele se torne um problema real. Veja Documentation / md.txt no kernel.

[exemplo de lavagem de disco] link

Você ainda precisa executar o smartmon em todas as unidades (uma vez por dia, fora das horas), analisar a saída e criar alarmes para evitar esse problema.

Pessoal, isso é o que os invasores de hardware fazem por você. A ironia é que temos todas as ferramentas para fornecer uma melhor experiência de MD, mas ninguém as une em uma solução integrada.

Você está praticamente no final da corrupção silenciosa de dados. Um fsck pode ajudá-lo, mas realmente a melhor coisa a fazer é consultar seus backups (você manteve os backups corretos? Os RAIDs não são backups) e se preparar para que esse RAID comece a afundar.

Então você encontrará o disco ruim.

Desculpe.

ENDUPDATE-8/21

Para começar, você leu a man page de badblocks para as opções que usou?

   -w     Use write-mode test. With this option, badblocks scans for bad  blocks  by  writing
          some  patterns (0xaa, 0x55, 0xff, 0x00) on every block of the device, reading every
          block and comparing the contents.  This option may not  be  combined  with  the  -n
          option, as they are mutually exclusive.

Então seus dados se foram, -n foi a versão não destrutiva. Talvez o que você realmente fez foi puxar um disco da matriz, executar badblocks nele e reinseri-lo? Por favor, esclareça.

O fato de você não saber qual disco falhou ao começar me diz que não é uma matriz de ataque MD. Então, quaisquer que sejam as ferramentas "raid" lvm inexistentes para ajudá-lo a se recuperar dessa falha simples, é isso que você precisa descobrir.

Eu diria que a maioria dos usuários usa uma solução de ataque MD. O restante se distrai com "o que é essa coisa?" ou "oh, isso é LVM, é o que eu devo fazer, certo?" e depois acaba onde você está agora. Imploro a implementação com ferramentas de gerenciamento terríveis que, na verdade, criaram mais riscos do que você tentou atenuar construindo um RAID 6 para começar.

Não é sua culpa, você não sabia. Francamente, eles devem desativar a coisa exatamente por esse motivo.

Em relação à reparação de blocos defeituosos. Você pode fazer isso colocando a máquina offline e inicializando em uma unidade USB viva e executando um dos seguintes procedimentos de reparo.

link

link

Quanto a onde esse setor está em sua matriz. Bem, você teria que considerar a rotação de paridade, que é uma PITA. Eu sugiro que você simplesmente verifique cada unidade até encontrar o problema.

Você pode ajudar a evitar isso no futuro ativando a "limpeza de disco" no MD, que lê e reescreve cada setor em uma janela de manutenção para descobrir exatamente esses tipos de problemas e potencialmente repará-los.

Espero que isso ajude.

    
por 20.08.2017 / 01:07