Ao fazer backup de alguns dados (um diretório inicial de 200 GB) com rsync, recebi um erro de E/0 para um arquivo específico, após o qualsincronizar novamentecontinuou "normalmente" com seu backup. O arquivo de origem do problema mostrou ter um tamanho de arquivo de 72 bytes.
Eu cancelei sincronizar novamentee executei o mesmo comando novamente. Desta vez, o mesmo arquivo mostrou estar transferindo dados.muitos dados...e mais dados e mais... Verifiquei o tamanho do arquivo de destino e era de até 13 GB! então usei Ctrl-c para cancelarsincronizar novamente.
Ao verificar novamente o tamanho do arquivo de origem, no Nautilus, ele mostrou um tamanho de 60.0 PB(Peta Bytes!) Em uma unidade de 500 GB.
Agora, o ponto principal de tudo isso: a exclusão deste arquivo causaria/poderia perda de dados em outros arquivos, visto que o sistema de arquivos pode percebê-lo como sendo muito maior do que realmente é... O sistema de arquivos é ext4..
Eu poderia simplesmente pular isso com umsincronizar novamenteexceção, mas estou particularmente interessado no que poderia acontecer se ele fosse excluído.
ATUALIZAÇÃO: tanto o destino quanto a origem sãoext4
Em relação às sugestões de ser um arquivo esparso: Se for um arquivo esparso, por que mostraria tamanhos diferentes de um minuto para o outro? O arquivo certamente(?) não estava em uso na época. É um ~/.macromedia/Flash_Player/#SharedObjects/someting-or-other.solarquivo, do qual existemmuitosmais tal.Solarquivos nesse diretório .. além disso, mostrou um erro de E/0 na primeira passagem.
Além disso, de acordo com man rsync, a opção sugerida -Sé lidar com arquivos esparsoseficientemente, nãoapropriadamente, então isso me sugere que mesmo que eu não estivesse usando -Sele deveria copiar um arquivo esparso com precisão em ambos os casos: o que não aconteceu, e mesmo se for um arquivo esparso, sendo 60,0 Peta Bytes parece certo (?) ser um erro no sistema de arquivos, em algum lugar... e essa é a minha principal preocupação: se houver uma falha no sistema de arquivos, a exclusão desse arquivo poderá ter repercussões em outros arquivos?
Mais especificamente: como gravou 13 GB de dados, e subindo! quando eu cancelei, ele também poderia excluir 13 GB - 60 PB de dados quando eu excluí-lo?
Responder1
Parece que o sistema de arquivos de origem está danificado, normalmente devido a um bug do kernel ou a uma RAM defeituosa (é mais provável que um disco danificado resulte em arquivos ilegíveis do que em dados corrompidos). Neste ponto, todas as apostas estão canceladas. No entanto, se a corrupção foi muito localizada, apenas o inode de um arquivo está corrompido e os outros arquivos não estão danificados, para que você possa excluir o arquivo com segurança. Observe que não há como testar essa suposição.
Minha recomendação é:
- Faça um teste de RAM ou conecte o disco em outra máquina.
- Certifique-se de ter feito backup de todos os seus dados.
- Verifique a integridade do disco com o SMART, se possível.
- Correr
fsck. - Se o disco ainda estiver bom, continue usando-o.
Responder2
É umarquivo esparso. Você deve considerar usar -S, para que o arquivo seja tratado da maneira mais adequada possível.
Responder3
Este é provavelmente umarquivo esparso. (se não estiver, comece a correragora!) Nãona verdadeocupar todo esse espaço, tem buracos. Talvez um grande buraco.
Exclua-o do rsynclado do destino e adicione a -Sopção (esparso) para rsyncgarantir que ele reconheça e lide com arquivos esparsos.
O tipo de sistema de arquivos de destino devesuporta arquivos esparsostambém. (versão curta: ext[234]sim, NTFS sim, FAT não)