"Erreur d'entrée / sortie" lors de l'accès à un répertoire
Je souhaite répertorier et supprimer le contenu d'un répertoire sur un disque dur amovible. Mais j'ai rencontré une "erreur d'entrée/sortie":
$ 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
Je me demandais quel était le problème?
Comment récupérer ou supprimer le répertoire pic et tout son contenu?
Mon système d'exploitation est Ubuntu 12.04, et le disque dur amovible a un système de fichiers ntfs. Les autres répertoires ne contenant pas ou à l'intérieur de pic sur le disque dur amovible fonctionnent correctement.
Ajoutée:
Dernière partie de la sortie de dmesg après avoir essayé de lister le contenu du répertoire:
[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
Les erreurs d'entrée/sortie lors des tentatives d'accès au système de fichiers signifient généralement des problèmes matériels.
Tapez dmesg et vérifiez les dernières lignes de sortie. Si le disque ou la connexion à celui-ci échoue, il y sera noté.
MODIFIER Le montez-vous via ntfs ou ntfs-3g? Si je me souviens bien, le pilote ntfs hérité n'avait pas de support d'écriture stable et a été largement abandonné lorsqu'il s'est avéré ntfs-3g était nettement plus stable et sécurisé.
Comme Sadhur le déclare, cela est probablement dû à des problèmes matériels du disque et la sortie dmesg est le bon endroit pour vérifier cela.
Vous pouvez effectuer une analyse de surface de votre disque à partir de Linux /sbin/badblocks /dev/sda.
Consultez la page de manuel pour des tests plus approfondis et des correctifs de base (relocalisation de bloc). Tout cela est indépendant du système de fichiers, il est donc sûr même avec un système de fichiers NTFS car il fonctionne au niveau de la "surface du disque".
Personnellement, je l'ai fait pour fonctionner sur une base mensuelle à partir de cron. Bien sûr, vous devez vérifier si vous recevez les e-mails cron dans votre boîte aux lettres (ce qui n'est souvent pas le cas par défaut). Ces e-mails finissent dans /var/mail/$USER ou similaire.
J'ai créé /etc/cron.d/badblocks:
30 4 * * 3 root [ -x /sbin/badblocks ] && [ $(date +\%d) -le 7 ] && /sbin/badblocks /dev/sda
Votre système de fichiers est endommagé, pour les volumes NTFS, vous devez exécuter un chkdsk sous le système Windows, mais il est presque impossible de le récupérer. Parfois, vous devrez peut-être formater le disque.
Une solution qui fonctionne pour moi consiste à rétrograder le ntfs-3g version de la version 2014 à la version 2012. Cela devrait résoudre votre problème d'accès à la partition ntfs. À long terme, ce n'est pas une solution, car vous devrez éventuellement exécuter la dernière version.
Plus d'infos ici
Je voulais juste ajouter ma solution à ce fil pour le bénéfice des autres - j'ai fait un peu de travail sur mon système lorsque mon alimentation était en panne - j'ai dû reconnecter les câbles SATA dans le mauvais ordre car lorsque je les ai commutés, tout a fonctionné à nouveau - aucune idée pourquoi le disque de démarrage devait être sur un port SATA spécifique, de toute façon, pourrait être la réponse pour quelqu'un d'autre.
Personne n'a mentionné quoi faire si les outils Linux ne fonctionnent pas et que seul un Mac, mais pas Windows, est disponible.
Peut être corrigé sur OS X avec Paragon NTFS
Dans mon cas, gparted a dit d'aller chercher un PC Windows qui était introuvable. Mais un Mac existait, pour lequel ce grand logiciel est disponible. Installer la version d'essai, effectuer vérifier , puis réparer - et voilà!
Je voulais juste partager mon expérience: sur FreeBSD 10.3, j'ai monté mon disque dur externe avec
$ Sudo ntfs-3g /dev/da0s1 /media
À l'intérieur du disque dur, j'ai fait un mkdir pour créer un répertoire, puis y ai déplacé quelques fichiers, bien sûr avec la commande mv. Enfin j'ai fait la commande suivante:
$ Sudo sync
J'ai ensuite monté le disque dur sur une machine Linux avec le noyau 4.4.0-78-generic. Maintenant, lorsque je liste le contenu du disque dur, le répertoire créé sur FreeBSD, nommé Jeff, est affiché comme ci-dessous:
$ ls -lhrtci
ls: cannot access 'Jeff': Input/output error
total 20K
? d????????? ? ? ? ? ? Jeff
De plus, lorsque j'essaie de supprimer le répertoire Jeff, je reçois le message d'erreur suivant:
$ Sudo rm -f -R Jeff
rm: cannot remove 'Jeff': Input/output error
Je ne pouvais pas me débarrasser du répertoire Jeff sur la machine Linux, j'ai donc utilisé la machine FreeBSD et remonté le disque dur sur FreeBSD. Mais les commandes ls, cd et rm sur FreeBSD génèrent le même Input/output error. Il semble qu'il y ait eu un bogue sur FreeBSD ntfs-3g paquet.
MISE À JOUR
J'ai déplacé toutes mes données du disque dur externe vers une machine Linux, bien sûr le fichier corrompu Jeff n'a pas pu être déplacé en raison d'une erreur d'E/S. Ensuite, j'ai reformaté le disque dur externe avec la mise à zéro du volume et la vérification du mauvais secteur comme ceci:
$ Sudo mkfs.ntfs /dev/sdb1
Et puis déplacé toutes les données vers le volume externe. De cette façon, j'ai perdu le fichier corrompu nommé Jeff, cependant, mon disque dur externe est exempt de toute erreur d'E/S.
J'ai publié que lorsque j'essaie d'accéder au disque qui se produit cette erreur, il a essayé d'écrire les derniers fichiers copiés ont été écrasés dans le dernier fichier, puis la tentative d'accès échoue parce que l'enregistrement déjà écrit ne correspond pas aux derniers éléments copiés, donc il échoue. La façon la plus saine de récupérer le disque consiste à supprimer le ou les derniers éléments copiés dans Windows.