wake-up-neo.com

디렉토리에 액세스 할 때 "입력 / 출력 오류"

이동식 하드 드라이브의 디렉토리 내용을 나열하고 제거하고 싶습니다. 그러나 "입력/출력 오류"가 발생했습니다.

$ rm  pic -R
rm: cannot remove `pic/60.jpg': Input/output error
rm: cannot remove `pic/006.jpg': Input/output error
rm: cannot remove `pic/008.jpg': Input/output error
rm: cannot remove `pic/011.jpg': Input/output error

$ ls -la pic
ls: cannot access pic/60.jpg: Input/output error
-????????? ? ?    ?         ?            ? 006.jpg
-????????? ? ?    ?         ?            ? 006.jpg
-????????? ? ?    ?         ?            ? 011.jpg

문제가 무엇인지 궁금했습니다.

pic 디렉토리와 그 내용을 모두 복구하거나 제거하려면 어떻게해야합니까?

내 OS는 Ubuntu 12.04이며 이동식 하드 드라이브에는 ntfs 파일 시스템이 있습니다. 이동식 하드 드라이브의 pic를 포함하지 않거나 포함하지 않는 다른 디렉토리는 정상적으로 작동합니다.


추가 :

디렉토리의 내용을 나열한 후 dmesg 출력의 마지막 부분 :

[19000.712070] usb 1-1: new high-speed USB device number 2 using ehci_hcd
[19000.853167] usb-storage 1-1:1.0: Quirks match for vid 05e3 pid 0702: 520
[19000.853195] scsi5 : usb-storage 1-1:1.0
[19001.856687] scsi 5:0:0:0: Direct-Access     ST316002 1A               0811 PQ: 0 ANSI: 0
[19001.858821] sd 5:0:0:0: Attached scsi generic sg2 type 0
[19001.861733] sd 5:0:0:0: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[19001.862969] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.865223] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.865232] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.867597] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.869214] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.869218] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.891946]  sdb: sdb1
[19001.894713] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.895950] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.895953] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.895958] sd 5:0:0:0: [sdb] Attached SCSI disk
[19113.024123] usb 2-1: new high-speed USB device number 3 using ehci_hcd
[19113.218157] scsi6 : usb-storage 2-1:1.0
[19114.232249] scsi 6:0:0:0: Direct-Access     USB 2.0  Storage Device   0100 PQ: 0 ANSI: 0 CCS
[19114.233992] sd 6:0:0:0: Attached scsi generic sg3 type 0
[19114.242547] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[19114.243144] sd 6:0:0:0: [sdc] Write Protect is off
[19114.243154] sd 6:0:0:0: [sdc] Mode Sense: 08 00 00 00
[19114.243770] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.243778] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.252797] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.252807] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.280407]  sdc: sdc1 < sdc5 >
[19114.289774] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.289779] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.289783] sd 6:0:0:0: [sdc] Attached SCSI disk
82
Tim

파일 시스템 액세스 시도 중 입/출력 오류는 일반적으로 하드웨어 문제를 의미합니다.

dmesg를 입력하고 마지막 몇 줄의 출력을 확인하십시오. 디스크 또는 디스크 연결에 실패하면 여기에 기록됩니다.

EDIT ntfs 또는 ntfs-3g? 내가 기억 하듯이 레거시 ntfs 드라이버는 no 안정적인 쓰기 지원을 가지고 있으며 ntfs-3g은 훨씬 더 안정적이고 안전했습니다.

36
Shadur

Sadhur가 말했듯이 이것은 디스크 하드웨어 문제로 인한 것일 수 있으며 dmesg 출력이이를 확인하기에 적합한 위치입니다.

리눅스에서 디스크의 표면 스캔을 할 수 있습니다 /sbin/badblocks /dev/sda.

기본 수정 사항 (블록 재배치)에 대한보다 철저한 테스트는 매뉴얼 페이지를 확인하십시오. 이것은 모든 파일 시스템에 구애받지 않으므로 '디스크 표면'수준에서 작동하는 NTFS 파일 시스템에서도 안전합니다.

나는 개인적으로 cron에서 매달 실행하도록했습니다. 물론 사서함에 크론 메일이 수신되는지 확인해야합니다 (기본적으로는 그렇지 않음). 이 메일은 /var/mail/$USER 또는 유사합니다.

내가 만들었다 /etc/cron.d/badblocks :

30 4 * * 3 root [ -x /sbin/badblocks ] && [ $(date +\%d) -le 7 ] && /sbin/badblocks /dev/sda
20
jippie

파일 시스템이 손상되었으므로 NTFS 볼륨의 경우 Windows 시스템에서 chkdsk을 실행해야하지만 복구가 거의 불가능합니다. 때로는 디스크를 포맷해야 할 수도 있습니다.

9
daisy

저에게 효과적인 해결책은 ntfs-3g 2014 릴리스에서 2012 릴리스까지의 버전입니다. 이것은 ntfs 파티션 액세스 문제를 해결해야합니다. 결국에는 최신 릴리스를 실행해야하기 때문에 장기적으로는 솔루션이 아닙니다.

더 많은 정보 여기

7
user50037

방금 다른 사람의 이익을 위해이 스레드에 솔루션을 추가하고 싶었습니다. 전원 공급 장치에 장애가 발생했을 때 시스템에서 일부 작업을 수행했습니다 .- 스위치를 켰을 때 SATA 케이블을 잘못된 순서로 다시 연결해야합니다. 모든 것이 다시 작동했습니다. 어쨌든 부트 디스크가 특정 SATA 포트에 있어야하는 이유를 전혀 알지 못합니다.

2
Alan Campbell

Linux 도구가 작동하지 않고 Windows 만 아니라 Mac 만 사용할 수있는 경우 수행 할 작업을 언급 한 사람은 없습니다.

Paragon NTFS 를 사용하여 OS X에서 수정 가능

제 경우에는 gparted는 찾을 수없는 Windows PC를 찾으라고했습니다. 그러나 Mac이 주변에 있었고,이 훌륭한 소프트웨어를 사용할 수있었습니다. 평가판을 설치하고 verify 를 수행 한 다음 복구 -그리고 성공!

2
BVengerov

방금 경험을 나누고 싶었습니다. FreeBSD 10.3에서 외장 하드 드라이브를 마운트했습니다.

$ Sudo ntfs-3g /dev/da0s1 /media

하드 드라이브 내에서 mkdir를 수행하여 디렉토리를 만든 다음 mv 명령을 사용하여 일부 파일을 디렉토리로 옮겼습니다. 마지막으로 다음 명령을 수행했습니다.

$ Sudo sync

그런 다음 커널 4.4.0-78-generic을 사용하는 Linux 시스템에 하드 드라이브를 마운트했습니다. 이제 하드 드라이브의 내용을 나열하면 FreeBSD에서 Jeff라는 디렉토리가 아래와 같이 표시됩니다.

$ ls -lhrtci
ls: cannot access 'Jeff': Input/output error
total 20K
  ? d????????? ? ?    ?       ?            ? Jeff

enter image description here

또한 Jeff 디렉토리를 제거하려고 할 때 다음 오류 메시지가 나타납니다.

$ Sudo rm -f -R Jeff
rm: cannot remove 'Jeff': Input/output error

enter image description here

Linux 시스템에서 Jeff 디렉토리를 제거 할 수 없으므로 FreeBSD 시스템을 사용하고 FreeBSD의 하드 드라이브를 다시 마운트했습니다. 그러나 FreeBSD의 ls, cdrm 명령은 동일한 Input/output error. FreeBSD에 버그가있는 것 같습니다. ntfs-3g 패키지.


최신 정보

모든 데이터를 외장 하드 드라이브에서 Linux 컴퓨터로 옮겼습니다. 물론 I/O 오류로 인해 손상된 파일 Jeff을 (를) 이동할 수 없습니다. 그런 다음 볼륨을 0으로 설정하고 불량 섹터를 다음과 같이 검사하여 외장 하드 드라이브를 다시 포맷했습니다.

$ Sudo mkfs.ntfs /dev/sdb1

그런 다음 모든 데이터를 다시 외부 볼륨으로 옮겼습니다. 이 방법으로 Jeff라는 손상된 파일을 잃어 버렸지 만 외장 하드 드라이브에 I/O 오류가 없습니다.

2
user3405291

이 오류가 발생하는 디스크에 액세스하려고하면 마지막으로 복사 한 파일을 마지막 파일에 쓰려고 시도했지만 이미 작성된 레코드가 마지막으로 복사 한 항목과 일치하지 않아 액세스 시도가 실패하여 실패했습니다. 디스크를 구출하는 가장 건강한 방법은 창에 마지막으로 복사 한 항목을 제거하는 것입니다.

0
cagcak