“Erro de entrada / saída” ao acessar um diretório

70

Eu quero listar e remover o conteúdo de um diretório em um disco rígido removível. Mas eu experimentei "erro de entrada / saída":

$ 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

Eu queria saber qual é o problema?

Como posso recuperar ou remover o diretório pic e todo o seu conteúdo?

Meu sistema operacional é o Ubuntu 12.04, e o disco rígido removível possui o sistema de arquivos ntfs. Outros diretórios que não contêm ou estão dentro de pic no disco rígido removível estão funcionando bem.

Adicionado:

Última parte da saída de dmesg depois tentei listar o conteúdo do diretório:

[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
    
por Tim 03.06.2012 / 00:37

8 respostas

31

Erros de entrada / saída durante tentativas de acesso ao sistema de arquivos geralmente significam problemas de hardware.

Digite dmesg e verifique as últimas linhas de saída. Se o disco ou a conexão estiver falhando, será anotado lá.

EDITAR Você está montando via ntfs ou ntfs-3g ? Pelo que me lembro, o driver legado ntfs tinha não suporte de gravação estável e foi largamente abandonado quando descobriu que ntfs-3g era significativamente mais estável e seguro.

    
por 03.06.2012 / 01:20
16

Como Sadhur afirma, isso provavelmente é causado por problemas de hardware de disco e a saída dmesg é o local certo para verificar isso.

Você pode emitir uma varredura de superfície do seu disco a partir do Linux /sbin/badblocks /dev/sda .

Verifique a página de manual para testes mais completos e correções básicas (realocação de blocos). Isso tudo é independente de sistemas de arquivos, portanto, é seguro mesmo com um sistema de arquivos NTFS, já que opera no nível de 'superfície de disco'.

Eu pessoalmente fiz isso para ser executado mensalmente pelo cron. É claro que você precisa verificar se você recebe os e-mails cron na sua caixa de correio (o que geralmente não é o caso por padrão). Esses e-mails acabam em /var/mail/$USER ou similares.

Eu criei /etc/cron.d/badblocks :

30 4 * * 3 root [ -x /sbin/badblocks ] && [ $(date +\%d) -le 7 ] && /sbin/badblocks /dev/sda
    
por 03.06.2012 / 09:54
8

Seu sistema de arquivos está danificado, para volumes NTFS você deve executar um chkdsk no sistema Windows, mas é quase impossível recuperar. Às vezes você pode precisar formatar o disco.

    
por 03.06.2012 / 03:06
6

Uma solução que funciona para mim é fazer o downgrade da versão ntfs-3g do lançamento de 2014 para o lançamento de 2012. Isso deve resolver seu problema de acesso à partição ntfs. No longo prazo, isso não é uma solução, porque, eventualmente, você precisará executar a última versão.

Mais informações aqui

    
por 02.05.2016 / 22:30
1

Eu só queria adicionar minha solução a este segmento para o benefício dos outros - eu fiz algum trabalho no meu sistema quando a minha fonte de alimentação falhou - eu devo ter reconectado os cabos SATA na ordem errada como quando eu os troquei, tudo funcionou de novo - não sei por que o disco de inicialização precisava estar em uma porta SATA específica, de qualquer forma, pode ser a resposta para outra pessoa.

    
por 20.11.2016 / 16:41
1

Ninguém mencionou o que fazer se as ferramentas do Linux não estiverem funcionando e apenas um Mac, mas não o Windows, estiver disponível.

Pode ser corrigido no Mac OS X com Paragon NTFS

No meu caso, gparted disse para encontrar um PC com Windows que não estava em lugar nenhum. Mas um Mac estava por perto, para o qual este excelente software está disponível. Instalei a versão de avaliação, executei verify , depois repare - e voilà!

    
por 13.01.2017 / 08:59
1

Eu só queria compartilhar minha experiência: no FreeBSD 10.3, montei meu disco rígido externo com

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

Dentro do disco rígido, eu fiz um mkdir para criar um diretório e movi alguns arquivos para ele, é claro, com o comando mv . Finalmente eu fiz o seguinte comando:

$ sudo sync

Depois montei o disco rígido em uma máquina Linux com o kernel 4.4.0-78-generic. Agora Quando eu listo o conteúdo do disco rígido, o diretório criado no FreeBSD, chamado Jeff , é mostrado abaixo:

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

Alémdisso,aotentarremoverodiretórioJeff,receboaseguintemensagemdeerro:

$sudorm-f-RJeffrm:cannotremove'Jeff':Input/outputerror

Eu não consegui me livrar do diretório Jeff na máquina Linux, portanto usei a máquina FreeBSD e montei novamente o disco rígido no FreeBSD. Mas os comandos ls , cd e rm no FreeBSD geram o mesmo Input/output error . Parece que houve um bug no pacote FreeBSD ntfs-3g .

UPDATE

Mudei todos os meus dados do disco rígido externo para uma máquina Linux, é claro que o arquivo corrompido Jeff não pôde ser movido devido a um erro de E / S. Em seguida, reformatei o disco rígido externo com o zeramento do volume e a verificação do setor como esta:

$ sudo mkfs.ntfs /dev/sdb1

Em seguida, todos os dados foram movidos de volta para o volume externo. Dessa forma, eu perdi o arquivo corrompido chamado Jeff , no entanto, meu disco rígido externo está limpo de qualquer erro de E / S.

    
por 08.06.2017 / 08:08
0

Eu liberei que quando tento acessar o disco que ocorre esse erro, ele tentou gravar os últimos arquivos copiados que foram gravados no último arquivo, depois a tentativa de acesso falha porque o registro já gravado não corresponde aos últimos itens copiados. falha. A maneira mais saudável de recuperar o disco é removendo o último item ou itens copiados nas janelas.

    
por 06.05.2018 / 18:40