将我的 postgres 主服务器同步到从服务器导致从服务器（journalctl）上出现写入 I/O 错误：
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
答案1
更新-8/22
如果你想快速解决这个问题，只需更换两个驱动器 具有最差的 smartctl 统计数据并重新评估。一旦您用完了保留块，您的驱动器就会 EOL。考虑到我们一次购买所有这些，它们往往会在同一时间发生故障。因此，坏块固定在哪一个并不重要。一旦您更换了最严重的两个违规者（这意味着更换一个并重新同步并重复），您将提高阵列的整体健康状况，可能更换了有问题的磁盘，并大大降低了丢失所有内容的双重故障风险。
最终，您的数据价值将超过几百美元。
结束更新-8/22
更新-8/21
Toni 是的，你原来的帖子还有改进的空间。考虑到这些事实，这就是我得出的结论。直到现在才清楚你已经遭受了数据损坏。
如果您将标题包含在 smartctl 输出中，将会很有帮助。这在 scsi 上更容易，sg_reassign 会告诉您还剩下多少个空闲块需要重新分配，一旦该值变为零，您就完成了。看到 smartctl 在几个类别中报告“prefail”，听起来您也很快就完成了。
很快您将遇到硬媒体错误，MD 将踢出驱动器。在此期间，fsck 会是一个好主意。当驱动器写入失败时，它们会从空闲块池中重新分配目标，当您用完时，它将成为不可恢复的媒体错误。
另外，在 MD 上启用“磁盘清理器”并每周按 cron 运行它，它将读取并重写每个扇区并在它成为真正的问题之前阻止它。请参阅内核中的文档/md.txt。
[磁盘清理器示例] https://www.ogre.com/node/384
您仍然必须运行所有驱动器的 smartmon（每天一次，非工作时间），解析输出，并创建警报以避免这个问题。
各位，这就是硬件突袭能为您做的事情。讽刺的是，我们拥有提供更好 MD 体验的所有工具，但没有人将它们整合成一个集成解决方案。
您几乎已经到了静默数据损坏的最后阶段。fsck 可能会有所帮助，但实际上最好的做法是参考您的备份（您保留了备份，对吧？RAID 不是备份）并准备让此 RAID 开始崩溃。
然后你就会找到坏的磁盘。
对不起。
结束更新-8/21
首先，您是否阅读过有关所使用的选项的 badblocks 手册页？
-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 是非破坏性版本。也许你真正做的是从阵列中取出一个磁盘，在其上运行坏块，然后重新插入它？请澄清一下。
您不知道哪个磁盘一开始就出现故障，这说明它不是 MD raid 阵列。因此，无论存在什么不存在的 lvm“raid”工具来帮助您从这个简单的故障中恢复，您都需要弄清楚。
我想说的是，大多数用户都选择了 MD RAID 解决方案。而剩下的人则会被“这是什么玩意？”或“哦，这是 LVM，我应该这么做，对吧？”所困扰，最后就落得了现在的境地。我用糟糕的管理工具实施 RAID，这实际上带来了比你通过构建 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 中启用“磁盘清理”来帮助防止将来出现这种情况，该功能会在维护窗口中读取并重写每个扇区，以准确发现此类问题并可能修复它们。
我希望这有帮助。