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
….
读取受影响的文件当然也不起作用：
cat base/96628250/96737718 >> /dev/null cat: 96737718: Input/output error
linux内核(ubuntu 16.04 4.4.0-87-generic)不应该自动从阵列中激活受影响的驱动器吗？
因为它是一个Raid6(顶层的LVM和ext4),我已经尝试用坏块覆盖每个SSD几次以引发错误(从raid中删除了一个又一个磁盘),遗憾的是没有成功.
smartctl说一个磁盘之前有错误(其他磁盘是干净的)：
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
但是用badblocks重写整个磁盘-wsv工作没有错误.
由于它对我来说是一个非常重要的服务器,我用不同的模型替换了整个服务器,但错误仍然存在.我是否认为它可能是磁盘问题？
有没有办法知道哪个磁盘受影响,可能是通过计算？
编辑：澄清：我没有得到的是从主设备到从设备的1.5 TB数据的初始同步如何导致两个不可恢复的I / O错误,但在每个涉及的SSD上手动运行破坏性读写测试完成任何错误.
EDIT2：lsblk的输出(对于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
更新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
更新2017-8-22 2
在pastebin上输出lsscsi和所有磁盘smartctl：https://pastebin.com/VUxKEKiF
解决方法
如果要快速解决此问题,只需更换两个驱动器即可
具有最差的smartctl统计数据并重新评估.一旦你没有保留块,你的驱动器就是EOL.看到我们一次性购买这些产品,它们往往会在同一时间内失败.所以哪个是无关紧要的
坏块被固定.一旦你替换了最糟糕的两个罪犯(这意味着更换一个并重新同步和重复),你将增加阵列的整体健康状况,可能取代了抱怨的磁盘,并大大降低了双重失败的风险,你失去了一切.
在一天结束时,您的数据价值超过几百美元.
ENDUPDATE-22分之8
UPDATE-21分之8
托尼是的,你的原帖有改进的余地.鉴于这些事实,这是我到达的结论.直到现在还不清楚你已经遭受了数据损坏.
如果您包含带有smartctl输出的标头会很有帮助.这在scsi上更容易,sg_reassign会告诉你剩下多少空闲块重新分配,一旦归零,你就完成了.看到smartctl在几个类别中报告“prefail”,听起来你很快就会完成.
很快你就会遇到硬媒体错误,而MD将会推动这一问题.同时fsck会是一个好主意.当驱动器写入失败时,他们会从空闲块池中重新分配目标,当您用完时,它将成为不可恢复的介质错误.
同时在MD上启用“磁盘清理程序”并在每周cron上运行它,它将读取并重写每个扇区并在它成为真正的问题之前关闭它.请参阅内核中的Documentation / md.txt.
[磁盘清理器示例]
https://www.ogre.com/node/384
您仍然必须运行所有驱动器的smartmon(每天一次,非工作时间),解析输出,并创建警报以阻止这个问题.
伙计们,这就是硬件袭击为你做的事情.具有讽刺意味的是,我们拥有提供更好的MD体验的所有工具,但没有人将它们整合到一个集成的解决方案中.
你几乎处于无声数据损坏的尾端. fsck可能对你有所帮助,但最好的办法是参考你的备份(你保持备份正确吗？RAID不是备份)并准备让这个RAID开始下沉.
然后你会找到坏磁盘.
抱歉.
ENDUPDATE-21分之8
对于初学者,您是否阅读了有关您使用的选项的坏块的手册页？
-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.
所以你的数据不见了,-n是非破坏性版本.也许你真正做的是从数组中取出一个磁盘,在其上运行badblocks,然后重新插入它？请澄清.
您不知道哪个磁盘无法启动,这告诉我它不是MD raid数组.因此,无论存在什么不存在的lvm“raid”工具来帮助您从这个简单的故障中恢复,这就是您需要弄清楚的.
我想说大多数用户都使用MD raid解决方案.剩下的人分心了“这是什么东西？”或者“哦,这是LVM,这是我应该做的,对吧？”然后结束你现在的位置.我使用糟糕的管理工具来实施实施,这些工具实际上比通过构建RAID 6而尝试缓解的风险更大.
这不是你的错,你不知道.坦率地说,他们应该因为这个原因而禁用它.
关于修复坏块.您可以通过使计算机脱机并启动到实时USB驱动器并执行以下某个修复过程来执行此操作.
https://sites.google.com/site/itmyshare/storage/storage-disk/bad-blocks-how-to
http://linuxtroops.blogspot.com/2013/07/how-to-find-bad-block-on-linux-harddisk.html
至于这个部门在你的阵列中的位置.那么,你必须考虑奇偶校验轮换,这是一个PITA.我建议你只需验证每个驱动器,直到找到问题为止.
您可以通过在MD中启用“磁盘清理”来帮助防止这种情况,该磁盘读取并重写维护窗口中的每个扇区以准确发现这些问题并可能修复它们.
我希望这有帮助.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。