Como identificar e corrigir arquivos com blocos de disco corrompidos / inacessíveis

9

Eu tenho um Macbook Pro de final de 2011, executando o Mavericks 10.9.2. Seu único HDD é uma unidade de 750 GB, formatada com Bootcamp. Ele ainda está funcionando razoavelmente bem, mas ao executar uma passagem de desfragmentação, identifiquei que há vários arquivos que se recusam a ser movidos pelo desfragmentador (iDefrag).

O iDefrag relata um código de erro POSIX 5 ao acessar os arquivos. Escolher um aleatoriamente e tentar copiar o arquivo para outro local no shell também informa um erro, o que me faz pensar que o problema é real e com o disco / FS. A saída de cp é:

cp: unity_nophysx.nexe: Input/output error

O código de erro 5 é 'acesso negado', pelo que sei, mas o processo de desfragmentação está sendo executado como administrador e a execução do cp usando o sudo no arquivo suspeito não faz diferença.

O Utilitário de Disco, fsck e o Apple Hardware Test afirmam que o disco está bom. Nenhum erro SMART foi relatado e, embora existam alguns erros de permissão, eles não estavam com os arquivos dos quais o iDefrag está reclamando, e o Disk Utility alega que os corrigiu sem reclamar.

Talvez haja cem ou mais arquivos corrompidos, mas ainda assim uma fração muito pequena da unidade. Até onde eu sei, nenhum arquivo do sistema ou dados cruciais são afetados. Embora seja bom recuperar os dados, não me importo de reinstalar ou fazer backups. Neste ponto, não sei se é realmente a unidade que está morrendo, apenas alguns setores defeituosos devido à movimentação da unidade durante a gravação ou alguma outra corrupção menor que pode ser contornada. Estou assumindo o pior caso, e que provavelmente terei que obter um HDD um pouco maior e clonar a unidade existente para evitar a reconstrução do sistema.

Minha pergunta é realmente como faço para marcar esses arquivos quebrados como corretamente quebrados e corrigi-los ou eliminá-los , para que um clone do disco seja bem-sucedido e não fique preso aos arquivos / blocos que não podem acessar. O Utilitário de Disco não está vendo o problema e não conheço nenhuma linha de comando ou ferramentas de terceiros que façam o trabalho. Não quero anular o disco inteiro e começar do zero, pois a unidade parece saudável, então estou procurando por ferramentas de reparo / diagnóstico.

— MrCranky
fonte

Aconselho que você leia esta discussão similar bastante detalhada no SuperUser: superuser.com/q/148227 .

— dan

Eu testei, infelizmente, em um disco saudável :), volitans-software.com/smart_utility.php . Parece uma ferramenta bastante simples e séria. Você pode experimentá-lo e, principalmente, verificar o contador "setores realocados".

— dan

8

Se você estiver enfrentando um sistema de arquivos íntegro no nível de sua estrutura e quiser encontrar arquivos com blocos com disco defeituoso, eis como devo proceder:

Faça um backup completo do seu disco com Time Machineou Carbon Copy Cloner

Verifique este backup.
Execute o seguinte comando pesado e arriscado (no caso de você ter blocos defeituosos fora da estrutura do sistema de arquivos) (verifique se {} está entre aspas para que os nomes de arquivos que contenham espaços funcionem):
```
find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
```

Esse findcomando pesado imprime para qualquer arquivo simples seu nome (portanto, não o lê, mas apenas sua entrada de diretório) e, em seguida, continua fazendo uma leitura completa e rápida de todos os seus blocos de dados.

Após a batia o primeiro arquivo que contém blocos ruins, isso findfará com que o kernel para log read erroron /var/log/system.log, e ele quer abrandar ou trazer o seu sistema a um impasse total. Isso dependerá principalmente da capacidade do disco rígido para realocar os blocos defeituosos encontrados em seu pool interno dedicado a essa tarefa de correção usual. Este arquivo contendo blocos inválidos será o sobrenome impresso por find.

Anote esse nome de arquivo em um pedaço de papel! Digamos que esse nome de arquivo seja:

/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9

Neste ponto, você pode ter a possibilidade de matar findrapidamente, pressionando ctrl+ C. Se matá-lo bem está falhando, basta travar o seu Mac.

Ao reiniciar o seu Mac, verifique diretamente o arquivo que contém os blocos defeituosos:

dd if='/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9' of=/dev/null bs=1m

Se o comando for finalizado corretamente, o erro será leve o suficiente para que seu disco possa ler esse arquivo e realocar os blocos defeituosos.

Se o comando não terminar, você não poderá matá-lo normalmente, seus dados serão totalmente perdidos e você precisará travar seu Mac mais uma vez.

Neste último caso, você deve considerar substituir seu disco e trabalhar com seus últimos backups. Alguns outros arquivos também podem conter blocos defeituosos e podem permanecer sem serem detectados há muito tempo, desde que você não os tenha lido.

O kernel não dispara um erro de leitura em um bloco que você nunca lê.

— dan
fonte

Ah, esse é absolutamente o tipo de truque que eu estava esperando. A primeira passagem com o script find / dd toca em todos os arquivos / blocos do disco e, com certeza, encontro vários arquivos que dão "Erro de entrada / saída", e posso simplesmente enviar o log do comando para um arquivo e então grep para descobrir quais arquivos estão duplicados. Parece que o comando dd não é o suficiente para acionar qualquer tipo de correção automática (eu nem sabia que o OS X fazia isso), mas pelo menos me fornece uma maneira confiável de identificar os arquivos.

— 10894 MrCranky

No lado positivo, quando o sistema operacional tenta ler os arquivos com esses blocos defeituosos, ele não trava ou desliga terrivelmente. Eu vejo um May 10 20:42:15 ICE kernel[0]: disk0s2: I/O error.pop-up nos logs, mas nenhuma pista sobre qual arquivo o acionou. Mas então o comando é executado com bastante satisfação.

— MrCranky

Seu kernel não trava com o BBFH porque seu disco ainda possui blocos suficientes disponíveis em seu pool para corrigir blocos defeituosos. ddnão conserta nada, esse objetivo do comando é copiar dados e convertê-los o mais rápido possível. O disco ainda pode reparar erros de luz. Fique atento, o preço de um disco não é nada comparado ao seu trabalho.

— dan

Mmm, sim, eu assumi que: dd é apenas uma ferramenta idiota para extrair todos os dados de um arquivo e colocá-los em outro lugar (no nosso caso, no ar). O que realmente importa é que todos os blocos associados ao arquivo sejam lidos. O que não estou conseguindo é o que você espera que o OS X faça nesse caso. Claramente, o kernel não pode ler esses blocos defeituosos, mas você acha que o próprio disco pode e pode corrigi-los? Se não é possível extrair os dados do bloco defeituoso original, como os transferirá para outro lugar?

— 10892 MrCranky

Excelente pergunta. O disco fará automaticamente novas tentativas nos blocos de leitura. Sempre que a posição da cabeça estiver mecanicamente em uma posição diferente. Se uma dessas tentativas tiver êxito, os dados serão copiados em um dos blocos disponíveis para reparar blocos defeituosos. O bloco com defeito é sinalizado como ruim e nunca será usado novamente. Por outro lado, se todas as novas tentativas falharem, os dados não serão salvos e, após muito tempo, o disco marcará o bloco como ruim e alocará um novo vazio no disco visível. O kernel reportará um erro irrecuperável no disco.

— dan

4

Reinicie no modo de usuário único mantendo pressionado o Command+ Sdurante a inicialização. Quando vir um prompt (deve ser semelhante root #ou algo semelhante), digite fsck -fe pressione Return. Esta é a ferramenta de verificação de consistência do sistema de arquivos do Mac e permite encontrar e reparar erros com o sistema de arquivos de inicialização. Execute este comando até não ver **The volume [volume name] was modified.**ou a ferramenta falhar três vezes seguidas.

Se a ferramenta falhar, pode ser um indicativo de um problema maior (mas eu não poderia lhe dizer o quê sem ver a saída da ferramenta). De qualquer forma, faça backup de tudo o que puder antes de executar qualquer ferramenta de disco. Quando terminar, digite rebooto prompt e pressione enter para (você adivinhou!) Reinicie o computador.

Para informações adicionais, você pode encontrar as páginas de manual do fsck aqui .

— Matt
fonte

Interessante, mas parece muito com o fsck, mesmo com -f e no modo de usuário único, está fazendo exatamente o que o Disk Utility fez. Como o Disk Utility, ele não encontra nada e acha que o disco está bom. Estou presumindo que ele esteja verificando os registros do sistema de arquivos, mas acho que meu problema está no nível do bloco - ou seja, o sistema de arquivos está bem estruturado, mas os dados reais dos arquivos não podem ser acessados quando se trata de leitura / copiando / desfragmentando-os.

— precisa saber é o seguinte

11

→ MrCranky: certo! fsck& Disk Utilityestão verificando a integridade da estrutura do sistema de arquivos. Eles lêem os blocos de disco alocados à estrutura do sistema de arquivos. Eles não são feitos para verificar a integridade dos blocos de dados. Portanto, eles podem ser executados em um disco com blocos defeituosos sem gerar nenhum erro de leitura. Se você deseja verificar seu disco, mesmo os blocos que podem estar com defeito, mas na verdade não são utilizados, basta usar uma ferramenta básica como dd if=/dev/disk0 of=/dev/null ibs=1ke dentro de outra janela da shell tail -f /var/log/system.log. Isso é gratuito, extremo e não oculta nenhum erro.

— dan

2

Eu recomendo o DiskWarrior para reconstruir catálogos de disco e verificar arquivos potencialmente danificados .

Durante a reconstrução do catálogo, também é possível informá-lo se houver um atraso devido ao mau funcionamento do disco.

— Adão
fonte

Não sou averso a comprar uma ferramenta para ajudar, mas sem tentativa e sem garantia de que ela foi projetada para encontrar o tipo de erro que estou enfrentando, precisaria de muito mais recomendações para fazer backup da sua antes de ser preparado para largar US $ 100 em uma ferramenta.

— precisa saber é o seguinte

-1 Não é apenas uma resposta, mas uma mistura de comentários e respostas.

— Max Ried

2

Trabalhando com a resposta de Buscar, você pode fazer isso automaticamente usando uma linha de comando bastante pesada.

sudo find / -type f -print0  | xargs -0 -I{} dd if='{}' of=/dev/null bs=1m 2>&1 | grep 'error' >>badfiles.txt  &

sudo: modo de administrador
find -print0: caminho absoluto
xargs -0 -I {}: substitui {} no próximo comando
dd 2> & 1: redirecionar erro std para stdout
stdout de pipe para grep procurando erro de string
Anexe os resultados a um arquivo de lista ( nota : isso deve estar na mídia externa se você acredita que sua unidade interna é duvidosa)

— awiebe
fonte

1

Como você diz, não está claro se esses arquivos estão danificados, pelo menos o seu Mac não acha.

Todo sistema operacional cria arquivos imóveis que são necessários para suas operações (pontos de restauração, arquivos atualmente ativos etc.). Alguns desfragmentadores os mostrarão, outros não.

O fato de você não poder acessá-los ou movê-los não significa que eles estejam danificados.

Normalmente, os Mac são muito bons em cuidar de si mesmos.

O uso da manutenção da Apple é feito por: abra o Terminal e digite:

sudo periodic daily weekly monthly

seguido por Return, digite sua senha de administrador e o OS X cuidará de tudo.

Procure no console os relatórios desses, se estiver interessado.

Enquanto estiver no console, procure (procure) por erros de E / S que indiquem que seu disco está começando a ter problemas, para complementar o Utilitário de Disco e as descobertas do fsck.

Ocasionalmente, uso uma ferramenta gratuita chamada OnyX para tarefas de manutenção adicionais. É feito por franceses e como eles comida é ótimo :)

_{OnyX é um utilitário multifuncional para OS X que permite verificar o disco de inicialização e a estrutura de seus arquivos de sistema, executar diversas tarefas de manutenção do sistema, configurar alguns parâmetros ocultos do Finder, Dock, QuickTime, Safari, Mail, iTunes , janela de login, Spotlight e muitos aplicativos da Apple, para excluir caches, remover um certo número de arquivos e pastas que podem se tornar pesados e muito mais.}

Com tudo isso dito, não estou questionando sua decisão de usar o desfragmentador (iDefrag), pois não o conheço, mas oferecendo soluções alternativas.

— Ruskes
fonte

O uso do desfragmentador não é o problema, estou perfeitamente ciente do que o OS X faz e não faz nesse sentido. Os arquivos definitivamente não estavam em uso, eram arquivos de dados para um aplicativo que não estava ativo e, de fato, o aplicativo agora não pode ser movido.

— MrCranky

Em Onyx - lo novamente está fazendo pouco mais do que o Utilitário de Disco faz - verificar o estado SMART do disco e, em seguida, executar o estilo fsck de diagnóstico (que, como nós estabelecemos pensa que não há nada errado)

— MrCranky

Só para esclarecer, para qualquer pessoa que esteja lendo esta resposta, os arquivos definitivamente foram danificados, e o Mac sabia disso, porque eu não tinha permissão para ler deles (copie-os, o que seja). Isso não era porque eles eram arquivos do sistema, ou em uso na época, era verdade mesmo para arquivos de dados do usuário. A manutenção periódica não ajudou no problema, porque, como fsckparece, ele se preocupa apenas com os problemas do sistema de arquivos, não bloqueia os problemas de acessibilidade. O console só mostrava erros quando eu tentei copiar / ler manualmente os dados de um desses arquivos quebrados, não ajudou em encontrá-los.

— MrCranky

0

Por mais irracional que pareça, antes de fazer qualquer coisa, você deve duplicar todos os seus dados em uma boa unidade conhecida. Se a inicialização do instalador e a cópia dos dados falhar, existe um utilitário de linha de comando chamado 'dd' que pode duplicar em baixo nível e de uma maneira muito mais intransigente.

 man dd

para obter mais informações sobre dd, incluindo uso e sintaxe adequada.

Outro voto para a postagem de Matt, inicialize o modo de usuário único e execute

 fsck -fy

repetidamente até que o fsck pare de relatar erros.

Uma votação para a publicação de Adam, o DiskWarrior é um aplicativo simples, mas muito poderoso, que relata falhas no HDD, verifica erros nos arquivos individuais e os repara, se possível, e reconstrói e otimiza as estruturas de diretórios.

Outra solução possível que pode parecer irracional, mas geralmente é uma última tentativa de recuperar dados com muitas evidências anedóticas de sucesso, é puxar a unidade, protegê-la da umidade usando algumas camadas de sacos do congelador e colocá-la no congelador para 30-45 minutos. Em seguida, enquanto a unidade estiver fria, monte-a em uma estação USB externa e use outro sistema temporário para tentar novamente copiar os dados corrompidos para outra unidade. Geralmente, isso é usado se houver um problema de hardware e a unidade estiver falhando. Se você pode duplicar a unidade inteira com seus dados intactos, isso é ideal, pois muitas vezes uma repartição e reformatação proporcionam uma nova vida útil à unidade.

— relaxando
fonte

Como eu disse, o fsck não relata erros. O disco ainda não está temperamental ou está relatando erros aleatórios, e a lista de arquivos corrompidos parece não estar aumentando, então não acredito que esteja perto do estágio de "congelamento para uma última retirada de emergência". Também já estou muito bem backup no nível de arquivo / pasta e não estou preocupado com a perda de dados, como disse na pergunta. É bom ouvir outro voto no DiskWarrior.

— MrCranky

@ MrCranky: Eu acredito que você se refere a algo publicado antes de atualizar sua pergunta; Eu estava reforçando a ideia do fsck para qualquer um que encontre esta página buscando uma solução para sintomas semelhantes. Em relação a qualquer coisa que eu publiquei sobre falha no HDD, nunca é demais ser abrangente, novamente, para os outros e não necessariamente para você. Eu já vi meu quinhão de falhas no disco rígido. Muitas vezes, não há indicação de falha, mesmo com a tecnologia SMART, até que você não possa mais acessar os dados por qualquer meio. Se você se importa com os dados, recomendo fortemente que você obtenha uma nova unidade e faça backup dos dados.

— Chillin

Certamente não discordo da recomendação para backup, mas o espírito do formato de perguntas e respostas é responder à pergunta que é feita, e não uma pergunta genérica "como faço para corrigir um disco quebrado" (dos quais existem muitos). Bem antes de editá-lo para adicionar fsckà lista de "coisas que acham que o disco está bom", eu respondi à resposta mencionando o fsckdesconto de sua utilidade. fscke o Disk Utility executam praticamente a mesma função, que é operar nas estruturas do sistema de arquivos, não no nível do bloco. Tentei ser bem específico de que este é um problema de bloco, não um problema no sistema de arquivos.

— MrCranky

0

Para um único arquivo que não pode ser lido na íntegra devido a um erro de leitura do disco, você pode usar o ddutilitário para duplicar o arquivo em um volume externo, substituindo NUL bytes pelos blocos que não podem ser lidos. É altamente recomendável duplicar para um volume diferente (por exemplo, "Disco USB" no exemplo abaixo).

Exemplo:

dd if=/path/to/damaged/file of=/Volumes/USB\ Disk/file bs=512 conv=noerror,sync

Usando blocos de 512 bytes, o número máximo de blocos legíveis será recuperado.

A recuperação pode levar muito tempo, pois o kernel bloqueará por algum tempo em cada leitura com falha.

— bleater
fonte