Centos7 - Erreur d'E / S de tampon sur dev sda, bloc logique xxxxxxxxx, écriture de page asynchrone perdue
J'ai un serveur Web qui contient le contenu de HP MSA2040 Storage (10 tb total de stockage).
Je continue à recevoir des erreurs comme ci-dessous
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
J'ai essayé d'exécuter xfs_repair sur/dev/sda qui est mon stockage MSA2040, voici le rapport que j'ai
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...
J'ai même essayé d'exécuter xfs_repaif -L Je peux accéder à mes données mais elles sont restées bloquées après un certain temps. J'ai également vérifié l'interface de MSA, tout semble fluide.
Existe-t-il une méthode pour résoudre ce problème?
Merci d'avance.
Modifier * Ceci est également un rapport 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 * Sorties demandées
[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]#
Edit * 3 - Quand je vérifie journalctl, maintenant je continue à recevoir ces journaux;
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)
Messages en tant que
Buffer I/O error on dev sda, logical block 886865171, lost async page write
signifie qu'une écriture asynchrone (c'est-à-dire: réécriture de page sale ou écritures tamponnées) a échoué. Vous avez trouvé ces erreurs dans dmesg ou /var/log/message parce que les écritures asynchrones qui ont échoué ne peuvent pas, de par leur nature même, être notifiées à l'application d'origine qui a soumis les écritures en premier lieu.
Ils sont souvent causés par un média où certains blocs ne peuvent pas être écrits. Cela peut se produire en raison de:
- plateaux/cellules de disque endommagés
- problèmes de connexion (c.-à-d. câble défectueux, cible iSCSI "perdue", etc.)
- périphérique de bloc à provisionnement fin dont l'espace du pool parent a été épuisé
Vous utilisez sda directement avec un système de fichiers sur le dessus, sans LVM côté nœud principal, nous pouvons donc exclure une mauvaise table de mappage de périphériques comme source de problème (sur le nœud principal, au moins).
Si les propriétés physiques de votre nœud de stockage sont correctes (c'est-à-dire: pas de disques défectueux, etc.), je suggère fortement de revoir tous les volumes à provisionnement fin et leurs pools parents.