系统日志中我的某个硬盘的错误消息“未处理的错误代码”、“I/O 错误”

Question

首先备份

在进行故障排除之前，请确保受影响硬盘 ( /dev/sdb) 上所需的所有数据都已备份。

备份有困难吗？

如果你遇到的 I/O 错误不是由文件系统损坏引起的（你表示结果fsck是干净的），并且你的数据对你来说确实很重要，那么最安全的恢复方法是使用gddrescue（或者dd_rescue，如果你更喜欢）。

以下是一个例子gddrescue：

ddrescue -Svv /dev/sdb /somewhere/else/rescue.img /somewhere/else/ddrescue.log

…/somewhere/else到具有比大小更多的可用空间的挂载的路径在哪里/dev/sdb。

gddrescue的日志文件/somewhere/else/ddrescue.log还可以帮助您识别硬盘中哪些区域无法读取。

一旦创建了驱动器的完整映像，您就可以使用其他工具恢复大部分可恢复的内容，例如测试磁盘或kpartx -av /somewhere/else/rescue.img和cryptsetup luksOpen，但这些超出了你的问题范围。

回答你的问题

有人之前见过这些和/或知道可能发生什么吗？

我处理硬盘的时间并不长，但我见过各种硬盘硬件问题。虽然我不是专家，但仍然很难确定你的特定硬盘可能发生了哪种故障。

我的硬盘出现故障了吗？

嗯，你的驱动器没有意识到它出现故障。

您尝试读取的次数越多，它就越有可能发现或有时导致更多问题，而写入操作有时会使情况变得更糟，这取决于存在何种损坏。

前几天我在启动时做了一次 fsck，但没有任何消息表明这一点。

硬件读取错误会影响文件的内容，但不会影响文件系统本身。

我还可以检查/做些什么来了解它的状况吗？

是的，我尝试在下面为您写一份全面的指南。

我为什么会收到这些错误？

导致硬盘 I/O 问题的原因有很多。

常见的情况是使用过程中用力过猛地摔落或移动硬盘。这种情况经常发生在像您这样的外置硬盘上。

另一个原因是您拥有 Seagate Barracuda，它往往不可靠：

^{_{（点击上图查看硬盘可靠性的评论。）}}

它也可能只是随机问题，可能只影响驱动器的一小部分或最终导致报废。

故障排除

本节中的命令是非破坏性的。

阅读个人行业

第一个问题迹象是内核记录 I/O 错误。尝试查看这些扇区是否可读：

time hdparm --read-sector 947918344 /dev/sdb

…947918344内核日志中记录的扇区号在哪里，以及/dev/sdb是否是疑似有问题的驱动器。

大多数硬盘驱动器都会尝试读取该扇区，因此可能需要一些时间。如果您立即收到 I/O 错误，则意味着驱动器肯定知道该扇区是禁止访问的，甚至不会尝试读取它。如果几秒钟后才收到 I/O 错误，则驱动器可能尝试读取该扇区但失败了。以下是立即发生的 I/O 错误的示例：

root@node51 [~]# time hdparm --read-sector 947918344 /dev/sdb

/dev/sdb:
reading sector 947918344: FAILED: Input/output error

real    0m0.038s
user    0m0.000s
sys     0m0.002s

以下是成功读取的示例：

root@node51 [~]# time hdparm --read-sector 947918344 /dev/sdb

/dev/sdb:
reading sector 947918344: succeeded
c193 76f6 7ae7 2dfa f121 b9ef 04da 2f82
4f6f 90af 6593 f215 d098 8857 2cfb d191
c6b1 245a 746c c1b8 bde9 f8f2 b3d2 ea68
3740 935d ce98 7fc6 bfef 41a5 f6b5 94e8
0833 6d39 3137 9b38 717d d310 f33d d508
d72d b504 77e5 7c8b 4496 6ac1 20f9 f49e
1224 8def df01 1163 d855 ae2b c6a8 eee5
3a22 04ae 012e bdd2 b5e9 94a4 3454 16ff
6000 81bc 356c a412 4b11 a875 588a 8394
37e5 310b f9eb afb6 4be1 0307 74f2 fce4
0f82 da8b 954f 4181 a544 ebff bfb5 4f1a
bcf9 e0be a912 fd78 e68d 9f76 424a 563f
0cc8 70ab 187e b7b1 b45d 732d 734d 0d7b
bb79 1e0c 8406 3fd9 5608 a6d4 9cd7 4167
ddb2 1972 7283 57bb 175e 1724 b3e4 9c07
0ba1 058d d8c9 b873 3e60 17e8 ab38 fad6
e9da b4e6 82f5 fb04 2316 b2ac 6cb3 05e1
7158 5a91 e21e 6333 f73e d839 e174 53bc
2f12 47dd 5dd2 d6d0 3d6d 7a6f a61c 7431
9e5f e3a2 55c5 1542 6efd 8b34 c40c 5382
a297 4627 2b64 1dc1 23bd 1442 f863 b1b1
767b c463 1936 ab96 b74c b899 7cae 632d
262d cef2 3088 2958 4d27 0f1b 9c44 ed30
f4ce 1d20 9a7e 2dca e99e 65bd 4686 2a8f
d3f4 f74a 35d3 e034 8473 9006 08d0 2372
0053 78fa d7ef 3f1a bcfd f702 376b c000
6517 3b41 5fb0 ff4c 87bb f79b 40ba 7bdf
c597 0246 663b 0ece 256d 26bd f806 e0f9
70b2 a1c8 ba4a 365d 69c6 e551 44d3 c840
7f9e 006d c1bc 07e5 c7df 5ca7 b37c 1de8
8d86 f118 e594 ede7 04b0 cc10 fac5 4070
a2a2 cd43 9ac6 fbd1 5790 eb60 fe65 f32d

real    0m0.014s
user    0m0.000s
sys     0m0.000s

如果现有扇区返回输入/输出错误，则表示存在问题。这可能意味着数据损坏。

SMART 扩展自检

您可以运行SMART 扩展离线自检使用以下命令：

smartctl -t long /dev/sdb

了解如何检查测试进度这里。

测试完成后，您可以使用以下命令检查其状态：

smartctl -l selftest /dev/sdb

下面是我“修复”过的硬盘的一个示例（即将解释）：

root@node51 [~]# smartctl -l selftest /dev/sdb
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     23316         -
# 2  Extended offline    Completed: read failure       30%     22068         1475120744
# 3  Extended offline    Completed without error       00%     19943         -
# 4  Short offline       Completed without error       00%     19940         -
1 of 1 failed self-tests are outdated by newer successful extended offline self-test # 1

以前，1475120744无法读取扇区，测试当时就失败了，但一段时间后，扇区就修好了？请继续阅读，了解这是怎么回事。

“修复”你的驱动器

如果您尝试这些命令，您可能会丢失数据。 确保您有足够的备份。

重新映射坏扇区

如果反复尝试，hdparm --read-sector驱动器速度会越来越慢，一段时间后还会返回 I/O 错误，那么数据可能永远都回不来了。您可以告诉硬盘驱动器将受影响的扇区重新映射到备用扇区，这样从您的角度来看，该扇区将完全被清空：

hdparm --yes-i-know-what-i-am-doing --write-sector 947918344 /dev/sdb

…947918344您要覆盖的扇区号在哪里。

备用扇区可能会用完，但如果发生这种情况，则表示您的驱动器已损坏，您应该更换它。（例子）

扫描和修复

驱动器只有看到坏扇区才能知道是否存在坏扇区。您可以使用以下方法扫描坏扇区badblocks：

badblocks -b 512 -s /dev/sdb

失败的读取将被记录到内核日志中，如您之前所见，并由输出badblocks。您可以使用此信息使用重新映射扇区hdparm --write-sector。

ATA 安全擦除

如果你不想等待badblocks或编写脚本来重新映射扇区，你可以清除所有坏扇区（以及您的所有其他数据）一气呵成。

笔记：这些指令可能无法通过 USB 接口起作用。

hdparm --security-set-pass password /dev/sdb
time hdparm --security-erase password /dev/sdb

重新映射并擦除`dd`

您还可以通过以下方式重新映射扇区擦除你的驱动器和dd：

dd conv=noerror if=/dev/zero of=/dev/sdb bs=2M

`dd`使用LUKS重新映射和擦除并保留

或者，如果您的 LUKS 设备在以下位置解密/dev/mapper/your-luks-device：

dd conv=noerror if=/dev/zero of=/dev/mapper/your-luks-device bs=2M

Answer 1

首先备份

在进行故障排除之前，请确保受影响硬盘 ( /dev/sdb) 上所需的所有数据都已备份。

备份有困难吗？

如果你遇到的 I/O 错误不是由文件系统损坏引起的（你表示结果fsck是干净的），并且你的数据对你来说确实很重要，那么最安全的恢复方法是使用gddrescue（或者dd_rescue，如果你更喜欢）。

以下是一个例子gddrescue：

ddrescue -Svv /dev/sdb /somewhere/else/rescue.img /somewhere/else/ddrescue.log

…/somewhere/else到具有比大小更多的可用空间的挂载的路径在哪里/dev/sdb。

gddrescue的日志文件/somewhere/else/ddrescue.log还可以帮助您识别硬盘中哪些区域无法读取。

一旦创建了驱动器的完整映像，您就可以使用其他工具恢复大部分可恢复的内容，例如测试磁盘或kpartx -av /somewhere/else/rescue.img和cryptsetup luksOpen，但这些超出了你的问题范围。

回答你的问题

有人之前见过这些和/或知道可能发生什么吗？

我处理硬盘的时间并不长，但我见过各种硬盘硬件问题。虽然我不是专家，但仍然很难确定你的特定硬盘可能发生了哪种故障。

我的硬盘出现故障了吗？

嗯，你的驱动器没有意识到它出现故障。

您尝试读取的次数越多，它就越有可能发现或有时导致更多问题，而写入操作有时会使情况变得更糟，这取决于存在何种损坏。

前几天我在启动时做了一次 fsck，但没有任何消息表明这一点。

硬件读取错误会影响文件的内容，但不会影响文件系统本身。

我还可以检查/做些什么来了解它的状况吗？

是的，我尝试在下面为您写一份全面的指南。

我为什么会收到这些错误？

导致硬盘 I/O 问题的原因有很多。

常见的情况是使用过程中用力过猛地摔落或移动硬盘。这种情况经常发生在像您这样的外置硬盘上。

另一个原因是您拥有 Seagate Barracuda，它往往不可靠：

^{_{（点击上图查看硬盘可靠性的评论。）}}

它也可能只是随机问题，可能只影响驱动器的一小部分或最终导致报废。

故障排除

本节中的命令是非破坏性的。

阅读个人行业

第一个问题迹象是内核记录 I/O 错误。尝试查看这些扇区是否可读：

time hdparm --read-sector 947918344 /dev/sdb

…947918344内核日志中记录的扇区号在哪里，以及/dev/sdb是否是疑似有问题的驱动器。

大多数硬盘驱动器都会尝试读取该扇区，因此可能需要一些时间。如果您立即收到 I/O 错误，则意味着驱动器肯定知道该扇区是禁止访问的，甚至不会尝试读取它。如果几秒钟后才收到 I/O 错误，则驱动器可能尝试读取该扇区但失败了。以下是立即发生的 I/O 错误的示例：

root@node51 [~]# time hdparm --read-sector 947918344 /dev/sdb

/dev/sdb:
reading sector 947918344: FAILED: Input/output error

real    0m0.038s
user    0m0.000s
sys     0m0.002s

以下是成功读取的示例：

root@node51 [~]# time hdparm --read-sector 947918344 /dev/sdb

/dev/sdb:
reading sector 947918344: succeeded
c193 76f6 7ae7 2dfa f121 b9ef 04da 2f82
4f6f 90af 6593 f215 d098 8857 2cfb d191
c6b1 245a 746c c1b8 bde9 f8f2 b3d2 ea68
3740 935d ce98 7fc6 bfef 41a5 f6b5 94e8
0833 6d39 3137 9b38 717d d310 f33d d508
d72d b504 77e5 7c8b 4496 6ac1 20f9 f49e
1224 8def df01 1163 d855 ae2b c6a8 eee5
3a22 04ae 012e bdd2 b5e9 94a4 3454 16ff
6000 81bc 356c a412 4b11 a875 588a 8394
37e5 310b f9eb afb6 4be1 0307 74f2 fce4
0f82 da8b 954f 4181 a544 ebff bfb5 4f1a
bcf9 e0be a912 fd78 e68d 9f76 424a 563f
0cc8 70ab 187e b7b1 b45d 732d 734d 0d7b
bb79 1e0c 8406 3fd9 5608 a6d4 9cd7 4167
ddb2 1972 7283 57bb 175e 1724 b3e4 9c07
0ba1 058d d8c9 b873 3e60 17e8 ab38 fad6
e9da b4e6 82f5 fb04 2316 b2ac 6cb3 05e1
7158 5a91 e21e 6333 f73e d839 e174 53bc
2f12 47dd 5dd2 d6d0 3d6d 7a6f a61c 7431
9e5f e3a2 55c5 1542 6efd 8b34 c40c 5382
a297 4627 2b64 1dc1 23bd 1442 f863 b1b1
767b c463 1936 ab96 b74c b899 7cae 632d
262d cef2 3088 2958 4d27 0f1b 9c44 ed30
f4ce 1d20 9a7e 2dca e99e 65bd 4686 2a8f
d3f4 f74a 35d3 e034 8473 9006 08d0 2372
0053 78fa d7ef 3f1a bcfd f702 376b c000
6517 3b41 5fb0 ff4c 87bb f79b 40ba 7bdf
c597 0246 663b 0ece 256d 26bd f806 e0f9
70b2 a1c8 ba4a 365d 69c6 e551 44d3 c840
7f9e 006d c1bc 07e5 c7df 5ca7 b37c 1de8
8d86 f118 e594 ede7 04b0 cc10 fac5 4070
a2a2 cd43 9ac6 fbd1 5790 eb60 fe65 f32d

real    0m0.014s
user    0m0.000s
sys     0m0.000s

如果现有扇区返回输入/输出错误，则表示存在问题。这可能意味着数据损坏。

SMART 扩展自检

您可以运行SMART 扩展离线自检使用以下命令：

smartctl -t long /dev/sdb

了解如何检查测试进度这里。

测试完成后，您可以使用以下命令检查其状态：

smartctl -l selftest /dev/sdb

下面是我“修复”过的硬盘的一个示例（即将解释）：

root@node51 [~]# smartctl -l selftest /dev/sdb
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     23316         -
# 2  Extended offline    Completed: read failure       30%     22068         1475120744
# 3  Extended offline    Completed without error       00%     19943         -
# 4  Short offline       Completed without error       00%     19940         -
1 of 1 failed self-tests are outdated by newer successful extended offline self-test # 1

以前，1475120744无法读取扇区，测试当时就失败了，但一段时间后，扇区就修好了？请继续阅读，了解这是怎么回事。

“修复”你的驱动器

如果您尝试这些命令，您可能会丢失数据。 确保您有足够的备份。

重新映射坏扇区

如果反复尝试，hdparm --read-sector驱动器速度会越来越慢，一段时间后还会返回 I/O 错误，那么数据可能永远都回不来了。您可以告诉硬盘驱动器将受影响的扇区重新映射到备用扇区，这样从您的角度来看，该扇区将完全被清空：

hdparm --yes-i-know-what-i-am-doing --write-sector 947918344 /dev/sdb

…947918344您要覆盖的扇区号在哪里。

备用扇区可能会用完，但如果发生这种情况，则表示您的驱动器已损坏，您应该更换它。（例子）

扫描和修复

驱动器只有看到坏扇区才能知道是否存在坏扇区。您可以使用以下方法扫描坏扇区badblocks：

badblocks -b 512 -s /dev/sdb

失败的读取将被记录到内核日志中，如您之前所见，并由输出badblocks。您可以使用此信息使用重新映射扇区hdparm --write-sector。

ATA 安全擦除

如果你不想等待badblocks或编写脚本来重新映射扇区，你可以清除所有坏扇区（以及您的所有其他数据）一气呵成。

笔记：这些指令可能无法通过 USB 接口起作用。

hdparm --security-set-pass password /dev/sdb
time hdparm --security-erase password /dev/sdb

重新映射并擦除`dd`

您还可以通过以下方式重新映射扇区擦除你的驱动器和dd：

dd conv=noerror if=/dev/zero of=/dev/sdb bs=2M

`dd`使用LUKS重新映射和擦除并保留

或者，如果您的 LUKS 设备在以下位置解密/dev/mapper/your-luks-device：

dd conv=noerror if=/dev/zero of=/dev/mapper/your-luks-device bs=2M

系统日志中我的某个硬盘的错误消息“未处理的错误代码”、“I/O 错误”

答案1

首先备份

备份有困难吗？

回答你的问题

故障排除

阅读个人行业

SMART 扩展自检

“修复”你的驱动器

重新映射坏扇区

扫描和修复

ATA 安全擦除

重新映射并擦除`dd`

`dd`使用LUKS重新映射和擦除并保留

相关内容

答案1

首先备份

备份有困难吗？

回答你的问题

故障排除

阅读个人行业

SMART 扩展自检

“修复”你的驱动器

重新映射坏扇区

扫描和修复

ATA 安全擦除

重新映射并擦除dd

dd使用LUKS重新映射和擦除并保留

相关内容

重新映射并擦除`dd`

`dd`使用LUKS重新映射和擦除并保留