Ao executar e2fsck -cck /dev/mapper/xxx sou solicitado com
has 487 multiply-claimed block(s), shared with 84 file(s):
... (inode #221446306, mod time Tue Feb 20 19:48:38 2018)
... (inode #221446305, mod time Tue Feb 20 19:48:32 2018)
... (inode #221446304, mod time Tue Feb 20 19:48:38 2018)
... (inode #221446303, mod time Tue Feb 20 19:48:12 2018)
... (inode #221446302, mod time Tue Feb 20 19:59:04 2018)
... (inode #221446300, mod time Tue Feb 20 19:47:52 2018)
Clone multiply-claimed blocks<y>?
Qual será a possível consequência de continuar com o sim. Haverá perda total de dados? Qual é o resultado se continuar com não?
Blocos de reivindicação múltipla são blocos que são usados por vários arquivos, quando não deveriam ser. Uma consequência disso é que as alterações em um desses arquivos, em um dos blocos afetados, também aparecerão como alterações nos arquivos que compartilham os blocos, o que não é o que você deseja. (Os links físicos são um cenário diferente, que não aparece aqui.)
Se houver perda de dados aqui, ela já ocorreu e não será facilmente reversível; mas pode ser pior...
Se você responder “não” à
fsck
pergunta, o sistema de arquivos permanecerá em um estado inconsistente. Se você responder "sim",fsck
copiará os blocos compartilhados para que possam ser realocados em um único arquivo - com os 84 arquivos envolvidos aqui, cada bloco seria copiado 83 vezes. Isso evitará a perda futura de dados, pois as alterações nos arquivos serão limitadas a cada arquivo individual, como seria de esperar. No entanto , a clonagem dos blocos pode envolver a substituição de dados em outros blocos, que atualmente parecem não ser usados, mas podem conter dados que você deseja manter.Portanto, o conselho tradicional de recuperação de dados se aplica: se você acha que precisa recuperar dados do sistema de arquivos, não toque nele; faça uma cópia dele em outro disco e trabalhe nisso para recuperar os dados. O cenário aqui onde isso pode ser desejável é o seguinte. Os arquivos A e B costumavam ser separados, mas após alguma corrupção em algum lugar, o arquivo B agora compartilha blocos com o arquivo A. Se nada substituiu os blocos antigos do arquivo B, os dados ainda estão lá, mas não estão mais acessíveis. Contanto que nada sobrescreva esses blocos, eles podem ser recuperados (com uma quantidade razoável de esforço, talvez). Mas uma vez que eles são substituídos, eles desaparecem; e aqui, clonar os blocos compartilhados do arquivo A pode substituir os dados antigos ...
Em resumo, se você possui backups ou sabe que os dados podem ser recuperados facilmente, responda “sim”. Caso contrário, pare
fsck
, copie o sistema de arquivos em outro lugar e, se precisar que o sistema volte a funcionar, executefsck
novamente e responda “sim” (e recupere os dados da cópia). Se os dados forem importantes e precisarem ser recuperados, copie o sistema de arquivos em outro lugar, mas deixe o original em paz - se você precisar que o sistema volte a funcionar, faça outra cópia e execute o sistema a partir dele, depois de executáfsck
-lo.