it-swarm-ja.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出力はこれをチェックするのに適切な場所です。

Linuxからディスクの表面スキャンを発行できます/sbin/badblocks /dev/sda

基本的な修正(ブロックの再配置)の詳細なテストについては、マニュアルページを確認してください。これはすべてファイルシステムに依存しないため、「ディスクサーフェス」レベルで動作するため、NTFSファイルシステムでも安全です。

私は個人的にこれを毎月cronから実行するようにしました。もちろん、メールボックスで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ツールが機能せず、MacではなくWindowsしか利用できない場合の対処法については誰も言及していません。

Paragon NTFS を使用してOS Xで修正できます

私の場合、gpartedはどこにも見つからなかったWindows PCを探しに行くと言いました。しかし、Macが出回っていたため、このすばらしいソフトウェアを入手できました。試用版をインストールし、verifyを実行してから、repairを実行しました。

2
BVengerov

私は自分の経験を共有したかっただけです。FreeBSD10.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のlscdおよびrmコマンドは、同じInput/output errorを生成します。 FreeBSD ntfs-3gパッケージにバグがあるようです。


更新

すべてのデータを外付けハードドライブからLinuxマシンに移動しましたが、I/Oエラーのため、破損したファイルJeffを移動できませんでした。次に、ボリュームのゼロ化と不良セクターチェックの両方を次のようにして、外付けハードドライブを再フォーマットしました。

$ Sudo mkfs.ntfs /dev/sdb1

その後、すべてのデータを外部ボリュームに戻しました。このようにして、Jeffという名前の破損したファイルを紛失しましたが、外部ハードドライブにはI/Oエラーがありません。

2
user3405291

このエラーが発生したディスクにアクセスしようとすると、コピーされた最後のファイルを書き込もうとしたときに、最後のファイルに上書きされ、すでに書き込まれたレコードが最後にコピーされたアイテムと一致しないためアクセスが失敗し、失敗します。ディスクをレスキューする最も健全な方法は、ウィンドウでコピーされた最後のアイテムを削除することです。

0
cagcak