Centos7 - Erro de E / S do buffer no dev sda, bloco lógico xxxxxxxxx, gravação da página assíncrona perdida

Navegue suas respostas
4

Eu tenho um servidor que possui o conteúdo no armazenamento HP MSA2040 (10 tb de armazenamento total).

Eu continuo recebendo erros como abaixo 

Jul 31 19:06:24 xxxxxxxx*** kernel: blk_update_request: I/O error, dev sda, sector 7094923416
Jul 31 19:06:24 xxxxxxxx*** kernel: buffer_io_error: 1110 callbacks suppressed
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865171, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865172, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865173, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865174, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865175, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865176, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865177, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865178, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865179, lost async page write
Jul 31 19:06:24 xxxxxxxx*** kernel: Buffer I/O error on dev sda, logical block 886865180, lost async page write

Eu tentei executar o xfs_repair em / dev / sda que é meu armazenamento MSA2040, este é o relatório que eu tenho 

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...

Eu até tentei executar xfs_repaif -L . Eu posso alcançar meus dados, mas ficou preso depois de algum tempo. Eu também verifiquei a interface do MSA, tudo parece bom.

Existe algum método para resolver este problema?

Obrigado antecipadamente.

Editar * Este também é um relatório smartctl 

=== START OF INFORMATION SECTION ===
Vendor:               HP
Product:              MSA 2040 SAN
Revision:             G210
User Capacity:        10,239,998,951,424 bytes [10.2 TB]
Logical block size:   512 bytes
LU is thin provisioned, LBPRZ=1
Rotation Rate:        15000 rpm
Logical Unit id:      0x600xxxxxxxxxxxxxxxef5701000000
Serial number:        00c0ff27xxxxxxxxxxxx701000000
Device type:          disk
Transport protocol:   Fibre channel (FCP-2)
Local Time is:        Mon Jul 31 19:22:30 2017 +03
SMART support is:     Available - device has SMART capability.
SMART support is:     Disabled
Temperature Warning:  Disabled or Not Supported

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Elements in grown defect list: 0

Error Counter logging not supported

Device does not support Self Test logging

Edit2 * Saídas solicitadas 

[root@xxxxxxxx*** thumbs]# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0  9.3T  0 disk /msa10tb
sdb               8:16   0  1.8T  0 disk
├─sdb1            8:17   0  200M  0 part /boot/efi
├─sdb2            8:18   0  500M  0 part /boot
└─sdb3            8:19   0  1.8T  0 part
  ├─centos-root 253:0    0   50G  0 lvm  /
  ├─centos-swap 253:1    0  7.8G  0 lvm  [SWAP]
  └─centos-home 253:2    0  1.8T  0 lvm  /home
sr0              11:0    1 1024M  0 rom
[root@xxxxxxxx*** thumbs]# pvs
  PV         VG     Fmt  Attr PSize PFree
  /dev/sdb3  centos lvm2 a--  1.82t 64.00m
[root@xxxxxxxx*** thumbs]# vgs
  VG     #PV #LV #SN Attr   VSize VFree
  centos   1   3   0 wz--n- 1.82t 64.00m
[root@xxxxxxxx*** thumbs]# lvs
  LV   VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home centos -wi-ao----  1.76t
  root centos -wi-ao---- 50.00g
  swap centos -wi-ao----  7.75g
[root@xxxxxxxx*** thumbs]#

Editar * 3 - Quando eu verifico o journalctl, agora continuo recebendo esses registros; 

Jul 31 19:29:46 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1461891501:1461898801 (repaired)
Jul 31 19:29:48 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1461891501:1461898801 (repaired)
Jul 31 19:29:50 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1461891501:1461898801 (repaired)
Jul 31 19:29:54 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1461891501:1461898801 (repaired)
Jul 31 19:30:03 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1461891501:1461898801 (repaired)
Jul 31 19:30:25 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1462932481:1462952921 (repaired)
Jul 31 19:30:27 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1462932481:1462952921 (repaired)
Jul 31 19:30:29 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1462932481:1462952921 (repaired)
Jul 31 19:30:30 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:5e37:2374:63273/443 unexpectedly shrunk window 3861953537:3862015916 (repaired)
Jul 31 19:30:31 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:5e37:2374:63273/443 unexpectedly shrunk window 3861953537:3862015916 (repaired)
Jul 31 19:30:32 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:5e37:2374:63273/443 unexpectedly shrunk window 3861953537:3862015916 (repaired)
Jul 31 19:30:33 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:1885:f5b0:30313/443 unexpectedly shrunk window 1462932481:1462952921 (repaired)
Jul 31 19:30:34 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:5e37:2374:63273/443 unexpectedly shrunk window 3861953537:3862015916 (repaired)
Jul 31 19:30:38 xxxxxxxx*** kernel: Peer 0000:0000:0000:0000:0000:ffff:5e37:2374:63273/443 unexpectedly shrunk window 3861953537:3862015916 (repaired)
    
por Lunatic Fnatic 31.07.2017 / 18:22

1 resposta

6

Mensagens como 

Buffer I/O error on dev sda, logical block 886865171, lost async page write

significa que uma gravação assíncrona (isto é: write-back de página suja ou gravações em buffer) falhou. Você encontrou esses erros em dmesg ou /var/log/message porque as gravações assíncronas com falha não podem, por sua própria natureza, ser notificadas ao aplicativo original que enviou as gravações em primeiro lugar.

Eles geralmente são causados por uma mídia em que alguns blocos não podem ser gravados. Isso pode acontecer devido a:

  • discos / células de disco danificados
  • problemas de conexão (por exemplo: cabo defeituoso, destino iSCSI "perdido", etc.)
  • dispositivo de bloco thinly provisioned cujo espaço de pool pai foi exaurido

Você está usando sda diretamente com um sistema de arquivos no topo, sem LVM no lado principal do nó, portanto podemos excluir uma tabela de mapeador de dispositivo ruim como uma fonte de problema (no nó principal, pelo menos).

Se as propriedades físicas do seu nó de armazenamento estiverem corretas (isto é, sem discos com defeito, etc.), sugiro veementemente revisar todos os volumes thinly provisioned e seus pools pai.

    
por 31.07.2017 / 22:20

Tags

Desativar GPO nega login de administradores de domínio Sistema de arquivos do Linux KVM Client (BTRFS?)