syslog의 내 하드 드라이브 중 하나에 대한 오류 메시지 "처리되지 않은 오류 코드" "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

syslog의 내 하드 드라이브 중 하나에 대한 오류 메시지 "처리되지 않은 오류 코드" "I/O 오류"

답변1

먼저 백업

백업하는 데 문제가 있나요?

귀하의 질문에 답변하기

문제 해결

개인 읽기분야

SMART 확장 자체 테스트

드라이브 "복구"

불량 섹터 다시 매핑

스캔 및 복구

ATA 보안 삭제

다시 매핑하고 지우기`dd`

`dd`LUKS를 사용하여 다시 매핑하고 지우고 보존합니다.

관련 정보

답변1

먼저 백업

백업하는 데 문제가 있나요?

귀하의 질문에 답변하기

문제 해결

개인 읽기분야

SMART 확장 자체 테스트

드라이브 "복구"

불량 섹터 다시 매핑

스캔 및 복구

ATA 보안 삭제

다시 매핑하고 지우기dd

ddLUKS를 사용하여 다시 매핑하고 지우고 보존합니다.

관련 정보

다시 매핑하고 지우기`dd`

`dd`LUKS를 사용하여 다시 매핑하고 지우고 보존합니다.