线上运维有时可以看到scrub报出的pg inconsistent错误，如果日志中有"head candidate had a read error"这样的字段，一般情况下，此问题是由磁盘坏道引起的概率较大。下面介绍一下此种错误的处理方法： 一、查找故障osd 使用"ceph pg ls inconsistent"查找发现问题的pg对应的osd，查找pg主osd的日志，找到故障osd，相关日志内容如下： 2017-06-19 14:02:02.260703 7fd8a05b1700 2 osd.184 pg_epoch: 27835 pg[44.1bfa( v 27835\'4859 (27759\'1800,27835\'4859] local-les=27622 n=599 ec=24958 les/c/f 27622/27622/0 27619/27621/24958) [184,68,49] r=0 lpr=27621 crt=27835\'4857 lcod 27835\'4858 mlcod 27835\'4858 active+clean+scrubbing+deep+inconsistent] 44.1bfa shard 68: soid 44:5fd867ab:::a3c7aedc-fcd5-47f3-8540-887817ea45b0.6953052.14_fa11613e1ad17d172_2386617676_925585214%2fOS45%2fDATA%2fBLOCK1035%2f1_31:***head candidate had a read error*** 二、确定磁盘坏道错误 （1）由deep scrub发现的此类错误通常是由磁盘故障引起的，磁盘出现坏道的可能性最大。登录到故障osd所在的主机，使用dmesg命令查看相关错误信息，磁盘坏道引起的scrub error会有如下信息： [onest]$ dmesg | tail -n 15 [26571207.965214] sd 0:0:6:0: [sdg] tag#0 Add. Sense: Unrecovered read error [26571207.965220] sd 0:0:6:0: [sdg] tag#0 CDB: Read(16) 88 00 00 00 00 00 06 c3 60 cO 00 00 00 08 00 00 [26571207.965225] blk_update_request: critical medium error, dev sdg, sector 113467590 [26571216.204547] sd 0:0:6:0 [sdg] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [26571216.204562] sd 0:0:6:0: [sdg] tag#0 Sense Key : Medium Error [current] [26571216.204568] sd 0:0:6:0: [sdg] tag#0 Add. Sense: Unrecovered read error [26571216.204575] sd 0:0:6:0: [sdg] tag#0 CDB: Read(16) 88 00 00 00 00 00 06 c3 60 cO 00 00 00 08 00 00 [26571216.204580] blk_update_request: critical medium error, dev sdg, sector 113467590 [26571216.206004] Buffer I/O error on device sdg, logical block 14183448 [26571225.719794] sd 0:0:6:0: [sdg] tag#0 FAILED Result: hostbyte=DID_0K driverbyte=DRIVER_SENSE [26571225.719806] sd 0:0:6:0: [sdg] tag#0 Sense Key : Medium Error [current] [26571225.719812] sd 0:0:6:0: [sdg] tag#0 Add. Sense: Unrecovered read error [26571225.719818] sd 0:0:6:0: [sdg] tag#0 CDB: Read(16) 88 00 00 00 00 00 02 b9 5a bO 00 00 00 08 00 00 [26571225.719822] blk_update_request: critical medium error, dev sdg, sector 45701814 [26571225.721610] Buffer l/O error on device sdg, logical block 5712726 使用MegaCli、smartctl可查看到错误发生频次相关信息： sudo /opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL | grep "Error Count" 相关error数量的统计，请对比来看 sudo smartctl -a /dev/sdg2 关注Raw_Read_Error_Rate等值，注意不同厂商对此值有不同的定义，请对比来看 （2）使用badblocks在dmesg出错位置确认磁盘坏道（注意磁盘多个分区、文件系统block与sector大小关系）： [onest]$ sudo badblocks -b 512 -s -v /dev/sdg 45701814 45701814 Checking blocks 45701814 to 45701814 Checking for bad blocks (read-only test): 45701814done, 0:05 elapsed. (0/0/0 errors) done Pass completed, 1 bad blocks found. (1/0/0 errors) 注：如果指定块序号超出32bit数字容量导致工具报错，可以增大指定的block大小。扇区大小使用fdisk命令可查。 如果磁盘在不同位置发生多次坏道错误（含历史），可以说明此坏道错误并发偶发，需要特别注意。 三、磁盘坏道处理 磁盘坏道可能是逻辑坏道，也可能是物理坏道，前者可能是断电、软件操作错误等磁盘的不当使用造成的，而物理坏道则意味着磁盘的物理属性已经发生改变。非偶发的逻辑坏道或者物理坏道，往往预示着磁盘的物理介质已经不稳定，磁盘有很大几率会有更多的故障发生，所以需要考虑尽快更换磁盘。 磁盘逻辑坏道可修复，物理坏道不能修复，只能进行临时屏蔽。对于逻辑坏道，进行修复处理后要进行历史记录，之后对于此磁盘要更多地进行关注。逻辑坏道的修复使用如下命令，其中END和START是需要修复的逻辑块号范围，最好停止osd服务后后再进行，请谨慎使用-f选项进行强制写入： badblocks -s -w /dev/sda END START 或者使用fsck对整个分区进行修复，需要停止osd服务，umount磁盘后再进行： fsck -a /dev/sdg2 在逻辑坏道修复完成后，再次进行坏道检测，如果仍然有坏道，则可判断其为物理坏道，物理坏道使用如下命令对坏道进行屏蔽，其中badblocks.log中记录出错的块号可由badblocks检测得到，也需要停止osd服务，umount磁盘后再进行： sudo fsck -l /tmp/badblocks.log /dev/sdg2 处理完成后，恢复osd服务。物理坏道只能屏蔽坏道作为临时处置手段，由于物理坏道有扩展性，一旦出现物理坏道，应该考虑尽快更换磁盘，以避免对产品稳定性造成影响。 注：对整个磁盘进行磁盘坏道检查的命令如下，但此过程耗时较长，可能花费数小时乃至更长时间，如果要了解磁盘的整体情况，可以指定部分磁道检测以供参考： badblocks -s -v -o /tmp/badblocks.log /dev/sdg2 END START 四、执行ceph pg repair XX命令，修复scrub error
